| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(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 17:25:35 |
| Message-ID: | 1179249935.24902.114.camel@dogma.v10.wvs |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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).
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-05-15 17:34:01 | Re: Invalid magic number in log file? |
| Previous Message | Bruce Momjian | 2007-05-15 17:18:42 | Re: Managing the community information stream |