From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, "Jeff Davis" <pgsql(at)j-davis(dot)com> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Simon Riggs" <simon(at)enterprisedb(dot)com>, "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>, "CK(dot)Tan" <cktan(at)greenplum(dot)com> |
Subject: | Re: Seq scans roadmap |
Date: | 2007-05-16 17:31:33 |
Message-ID: | C2708E05.3055D%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I think the analysis on syncscan needs to take the external I/O cache into
account. I believe it is not necessary or desirable to keep the scans in
lock step within the PG bufcache.
The main benefit of a sync scan will be the ability to start the scan where
other scans have already filled the I/O cache with useful blocks. This will
require some knowledge of the size of the I/O cache by the syncscan logic,
but that's where the largest amount of I/O cache memory (by far) is located.
- Luke
On 5/15/07 3:34 PM, "Jim C. Nasby" <decibel(at)decibel(dot)org> wrote:
> On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote:
>> On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
>>> Luke Lonergan wrote:
>>>> 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
>>>> effect.
>>>>
>>>> How about using 256/blocksize?
>>>
>>> Sounds reasonable. We need to check the effect on the synchronized
>>> scans, though.
>>>
>>
>> I am a little worried that there will be greater differences in position
>> as the number of scans increase. If we have only 8 buffers and several
>> scans progressing, will they all be able to stay within a few buffers of
>> eachother at any given time?
>>
>> Also, with 8 buffers, that means each scan must report every 4 pages at
>> most (and maybe every page), which increases lock contention (the new
>> design Heikki and I discussed requires a lock every time a backend
>> reports its position).
>
> Given that spoiling the L2 cache is a trivial cost compared to extra
> physical IO, ISTM we should go with a largish ring for sync scans. What
> do you think would be the ideal size? 32 buffers?
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-05-16 17:32:19 | Re: Lack of urgency in 8.3 reviewing |
Previous Message | Guido Barosio | 2007-05-16 17:30:32 | Re: Lack of urgency in 8.3 reviewing |