Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Date: 2008-01-31 02:15:35
Message-ID: 200801310215.m0V2FZG15153@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Another question --- why don't we just turn off synchronized_seqscans
> > when we do COPY TO?  That would fix pg_dump and be transparent.
> 
> Enforcing this from the server side seems a pretty bad idea.  Note that
> there were squawks about having pg_dump behave this way at all; if the
> control is on the pg_dump side then at least we have the chance to make
> it a user option later.
> 
> Also, you forgot about pg_dump -d.

OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
have to recognize that GUC forever.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-01-31 03:18:03
Subject: Re: Oops - BF:Mastodon just died
Previous:From: Christopher BrowneDate: 2008-01-31 02:13:37
Subject: Re: [PATCHES] Better default_statistics_target

pgsql-patches by date

Next:From: Tom LaneDate: 2008-01-31 05:42:07
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Previous:From: Christopher BrowneDate: 2008-01-31 02:13:37
Subject: Re: [PATCHES] Better default_statistics_target

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group