Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Дата
Msg-id 200801310138.m0V1cVW21111@momjian.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> > > I'm still not very happy with any of the options here.
> > 
> > > BAS is great if you didn't want to trash the cache, but its also
> > > annoying to people that really did want to load a large table into
> > > cache. However we set it, we're going to have problems because not
> > > everybody has the same database.
> > 
> > That argument leads immediately to the conclusion that you need
> > per-table control over the behavior.  Which maybe you do, but it's
> > far too late to be proposing it for 8.3.  We should put this whole
> > area of more-control-over-BAS-and-syncscan on the TODO agenda.
> 
> Another question --- why don't we just turn off synchronized_seqscans
> when we do COPY TO?  That would fix pg_dump and be transparent.

Sorry, I was unclear. I meant don't have a GUC at all but just set an
internal variable to turn off synchronized sequential scans when we do
COPY TO.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable