Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Date
Msg-id 200801310133.m0V1XXk20450@momjian.us
Whole thread Raw
In response to Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable  (Bruce Momjian <bruce@momjian.us>)
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Oops - BF:Mastodon just died
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable