From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | "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-27 18:37:29 |
Message-ID: | 26831.1201459049@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> writes:
>>> Maybe a GUC variable to enable/disable syncscan?
> If so, it seems like a good idea even if it's just for debugging purposes.
Do we have nominations for a name? The first idea that comes to mind
is "synchronized_scanning" (defaulting to ON).
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2008-01-27 19:15:37 | Re: CLUSTER and synchronized scans and pg_dump et al |
Previous Message | Guillaume Smet | 2008-01-27 18:22:57 | Re: CLUSTER and synchronized scans and pg_dump et al |