| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Gregory Stark <stark(at)enterprisedb(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-07 05:46:34 |
| Message-ID: | 6303.1165470394@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Even if there are 50 in the pack, and 2 trailing, at any point in time
> it's more likely that the last block number reported was reported by a
> trailing scan. The pack might all report at once when they finally get
> the block, but will be promptly overwritten by the continuous stream of
> reports from trailing scans.
> However, if my analysis was really true, one might wonder how those
> scans got that far behind in the first place.
Yah. Something I was idly wondering about: suppose we teach ReadBuffer
to provide an indication whether it had to issue an actual read() or
found the block in cache? Could it be useful to not report the block
location to the hint area if we had to actually read()? That would
eliminate the immediate "pack leader" from the equation. The problem
is that it seems to break things for the case of the first follower
joining a seqscan, because the original leader would never report.
Anyone see the extra idea needed to make this work?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ITAGAKI Takahiro | 2006-12-07 06:05:52 | Load distributed checkpoint |
| Previous Message | Jeff Davis | 2006-12-07 00:59:37 | Re: old synchronized scan patch |