Re: CLUSTER and synchronized scans and pg_dump et al

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
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-28 15:23:13
Message-ID: 479D9F01.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> On Mon, Jan 28, 2008 at 9:00 AM, in message <479DEDF5(dot)4090909(at)dunslane(dot)net>,
Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Kevin Grittner wrote:
>>>>> On Sun, Jan 27, 2008 at 9:02 AM, in message
>> <87odb7s45i(dot)fsf(at)oxford(dot)xeocode(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>
>> wrote:
>>
>>> Perhaps we should have some form of escape hatch for pg_dump to request real
>>> physical order when dumping clustered tables.
>>
>> It would seem reasonable to me for pg_dump to use ORDER BY to select
>> data from clustered tables.
>
> What will be the performance hit from doing that?

If the rows actually are in order of the clustered index, it
shouldn't add much more than the time needed to sequentially pass
the clustered index, should it? Even so, perhaps there should be a
command-line option on pg_dump to control whether it does this.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gevik Babakhani 2008-01-28 16:07:09 system catalog constraints question
Previous Message Andrew Dunstan 2008-01-28 15:00:05 Re: CLUSTER and synchronized scans and pg_dump et al