From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Luke Lonergan <llonergan(at)greenplum(dot)com>, pgsql-hackers(at)postgresql(dot)org, Eng <eng(at)intranet(dot)greenplum(dot)com> |
Subject: | Re: old synchronized scan patch |
Date: | 2006-12-05 17:39:07 |
Message-ID: | 1165340347.4302.86.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2006-12-05 at 11:28 +0100, Zeugswetter Andreas ADI SD wrote:
> > To open up the implementation topic:
> >
> > My current patch starts a new sequential scan on a given relation at
> the
> > page of an already-running scan.
>
> I think it should start earlier to make use of the already cached part
> of the table.
> It is hard to determine, or guess how much is still in cache though.
> As a start you could maybe use some (small to be safe) fraction of
> effective_cache_size
> or shared_buffers.
Interesting idea, however it's a little tricky. For instance, we don't
want to start before the oldest cached page, or we have lost the benefit
(just as if we got a bad hint). It also depends on a lot of other parts
of the code, like how scan-resistant the shared buffers are, and how
scan-resistant the OS buffer cache is.
Thoughts?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Mitchell | 2006-12-05 17:41:33 | Re: Storing a dynahash for an entire connection or |
Previous Message | Jeff Davis | 2006-12-05 17:32:37 | Re: old synchronized scan patch |