Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
ktm@rice.edu <ktm@rice.edu>
From: Kenneth Marshall <ktm@rice.edu>
To: Zeugswetter Andreas ADI SD <Andreas.Zeugswetter@s-itsolutions.at>
Cc: Guillaume Smet <guillaume.smet@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira de Oliveira <euler@timbira.com>, Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <heikki@enterprisedb.com>, Neil Conway <neilc@samurai.com>, Gregory Stark <stark@enterprisedb.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, pgsql-hackers@postgresql.org
Date: 2008-01-30T13:25:18Z
Lists: pgsql-hackers
On Wed, Jan 30, 2008 at 10:56:47AM +0100, Zeugswetter Andreas ADI SD wrote: > > > > The plural seems better to me; there's no such thing as a solitary > > > synchronized scan, no? The whole point of the feature is to affect > > > the behavior of multiple scans. > > > > +1. The plural is important IMHO. > > ok, good. > > > As I stated earlier, I don't really like this argument (we already > > broke badly designed applications a few times in the past) but we > > really need a way to guarantee that the execution of a query is stable > > and doesn't depend on external factors. And the original problem was > > to guarantee that pg_dump builds a dump as identical as possible to > > the existing data by ignoring external factors. It's now the case with > > your patch. > > The fact that it allows us not to break existing applications relying > > too much on physical ordering is a nice side effect though :). > > One more question. It would be possible that a session that turned off > the synchronized_seqscans still be a pack leader for other later > sessions. > Do/should we consider that ? > > The procedure would be: > start from page 0 > iff no other pack is present fill the current scan position for others > I think that allowing other scans to use the scan started by a query that disabled the sync scans would have value. It would prevent these types of queries from completely tanking the I/O. +1 Ken