| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 17:59:54 |
| Message-ID: | 87slfukyud.fsf@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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. The clock
sweep method is supposed to be especially resistant to this since it doesn't
really matter how many times something is accessed, only whether it has been
accessed recently. As long as all the synchronized scans get their work done
before the clock comes around the block will be recycled the next time the
clock sweeps around and it finds nobody else is interested in that block.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Welche | 2006-12-05 18:06:18 | unique key and nulls |
| Previous Message | Volkan YAZICI | 2006-12-05 17:58:25 | Preserving Cluster-Wise Data |