Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
От | Zeugswetter Andreas ADI SD |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA57902C23FC1@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Ответы |
Re: [PATCHES] Proposed patch: synchronized_scanning
GUCvariable
Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable |
Список | pgsql-hackers |
> > 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 Andreas
В списке pgsql-hackers по дате отправления: