Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Дата
Msg-id 24107.1201633753@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  ("Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>)
Ответы Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Список pgsql-hackers
"Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at> writes:
> synchronize[d]_seqscan sounds a bit better in my ears than the plural
> synchronize_seqscans.

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.

BTW, so far as the rest of the thread goes, I'm not necessarily opposed
to exposing the switchover threshold as a tunable.  But I think it needs
more thought to design than we can give it in time for 8.3 (because of
the interaction with the buffer access strategy stuff).  Also I don't
like having pg_dump manipulating a tuning parameter.  I don't see
anything wrong with having both an on/off feature switch and a tunable
in future releases.  The feature switch can be justified on grounds
of backwards compatibility quite independently of whether pg_dump uses
it.  Or is someone prepared to argue that there are no applications out
there that will be broken if the same query, against the same unchanging
table, yields different results from one trial to the next?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Large pgstat.stat file causes I/O storm
Следующее
От: Cristian Gafton
Дата:
Сообщение: Re: Large pgstat.stat file causes I/O storm