From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Luke Lonergan <LLonergan(at)greenplum(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-15 22:46:51 |
Message-ID: | 464A385B.8020107@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
I'm not sure. Needs testing. Assuming the scan leaves behind a cache
trail in the OS cache as well, it might not be that bad if a scan
joining the party starts a little bit behind.
> 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).
Keep in mind that processing a 32K page takes longer than processing an
8K page.
But we'll see..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-05-15 22:50:10 | Re: 8.3 pending patch queue |
Previous Message | Russell Smith | 2007-05-15 22:42:13 | Re: [HACKERS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped) |