| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Hannu Krosing" <hannu(at)skype(dot)net>, "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 18:25:15 |
| Message-ID: | 8925.1165343115@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Sure, it should hang around for awhile, and will. The problem is that
>> its lifetime will be artificially inflated, so that the seqscan ends up
>> kicking out other blocks that are really of greater importance, rather
>> than recycling its own old blocks as it should.
> I thought you had switched this all to a clock sweep algorithm.
Yeah ... it's a clock sweep with counter. A buffer's counter is
incremented by each access and decremented when the sweep passes over
it. So multiple accesses allow the buffer to survive longer. For a
large seqscan you really would rather the counter stayed at zero,
because you want the buffers to be recycled when the sweep comes back
the first time.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-12-05 18:27:52 | Re: Preserving Cluster-Wise Data |
| Previous Message | Volkan YAZICI | 2006-12-05 18:15:14 | Re: Preserving Cluster-Wise Data |