Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Дата | |
Msg-id | 200801310133.m0V1XXk20450@momjian.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Proposed patch: synchronized_scanning
GUC variable
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Список | pgsql-hackers |
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. -- 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 по дате отправления: