Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.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-31T01:38:31Z
Lists: 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. +