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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2008-01-28 22:58:13 Re: Proposed patch: synchronized_scanning GUC variable
Previous Message Simon Riggs 2008-01-28 22:39:41 Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable