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

Re: CLUSTER and synchronized scans and pg_dump et al

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER and synchronized scans and pg_dump et al
Date: 2008-01-28 22:44:52
Message-ID: 1201560292.10057.647.camel@dogma.ljc.laika.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 2008-01-27 at 13:37 -0500, Tom Lane wrote:
> Also, does anyone object to making pg_dump just disable it
> unconditionally?  Greg's original gripe only mentioned the case of
> clustered tables, but it'd be kind of a pain to make pg_dump turn it
> on and off again for different tables.  And I could see people
> complaining about pg_dump failing to preserve row order even in
> unclustered tables.
> 

If you are running pg_dump, that increases the likelihood that multiple
sequential scans will be reading the same large table at the same time.
Sync scans prevent that additional scan from bringing your active
database to a halt during your dump (due to horrible seeking and poor
cache efficiency).

I think that pg_dump is a good use case for synchronized scans. Assuming
it doesn't hold up 8.3, I think it's worthwhile to consider only
disabling it for tables that have been clustered.

That being said, this isn't a strong objection. Having a painless 8.3
release is the top priority, of course.

Regards,
	Jeff Davis


In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2008-01-28 22:58:13
Subject: Re: Proposed patch: synchronized_scanning GUC variable
Previous:From: Simon RiggsDate: 2008-01-28 22:39:41
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

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