Re: old synchronized scan patch

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(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>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org>, "Eng" <eng(at)intranet(dot)greenplum(dot)com>
Subject: Re: old synchronized scan patch
Date: 2006-12-07 11:05:43
Message-ID: 87r6vcj794.fsf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Csaba Nagy" <nagy(at)ecircle-ag(dot)com> writes:

> 1) How about 2 location hints, one for the actual reads, and one for the
> followers ?

Having the location of the pack leader may be useful for another reason too:
It would give the trailers a chance to avoid competing with the pack leader.

I would expect no matter how far back they start they'll quickly catch up to
the pack leader since they're only doing cached reads and the pack leader is
having to do actual i/o. When they catch up they're going to compete for the
lead which may a) kill the kernel read-ahead and b) cause contention.

If they know where the oldest trailer is and where the leader is then when
they catch up they could sleep for a small amount of time to give the leader a
chance to make progress.

I would suggest they should only sleep once and if they catch up again they
should try to take over and become the new leader. If the leader ever finds
its reading a cached block and someone else has passed it it should switch to
follower behaviour. That way the leadership does change hands periodically but
not on every read. Just in case the first leader is, say, running a nested
loop or something we don't want the follower to be unnecessarily limited to
its speed.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hubert FONGARNAND 2006-12-07 11:28:50 Re: Bug in PostGreSQL 8.2
Previous Message Gregory Stark 2006-12-07 10:57:02 Re: old synchronized scan patch