Re: old synchronized scan patch

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 00:59:37
Message-ID: 1165453177.2048.112.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2006-12-06 at 15:12 -0500, Tom Lane wrote:
> > Teamwork requires some synchronisation to be effective, but yeh there
> > needs to be a way to leave the Conga if its not working for you/them.
>
> If we have syncscan members that are spread out over any significant
> range of the table's blocks, then the problem of setting the hint
> properly becomes a lot more pressing. We'd like incoming joiners to
> start at a fairly low block number, ie not become one of the "pack
> leaders" but one of the "trailers" --- since the higher they start,
> the more blocks they'll need to re-read at the end of their cycles,
> yet those are blocks they could have had "for free" if they'd started
> as a trailer. I don't see any cheap way to bias the behavior in that
> direction, though.
>

This is speculation, but I suspect that there already is somewhat of a
bias favoring the lower block numbers. If you have a pack near the head,
and a couple trailers 1000 blocks behind, the trailers are likely to be
moving through those blocks very quickly -- and reporting their location
much more often -- than the blocks at the head that are awaiting a disk
fetch.

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.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-07 05:46:34 Re: old synchronized scan patch
Previous Message Bruce Momjian 2006-12-07 00:49:14 Heading to Mexico