Re: pg_dump performance lossage for primary keys - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: pg_dump performance lossage for primary keys
Date
Msg-id 20010403150100.D24063@rice.edu
Whole thread Raw
In response to Re: pg_dump performance lossage for primary keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 03, 2001 at 03:34:51PM -0400, Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> 
> > We really need ALTER TABLE ADD CONSTRAINT for PK.
> 
> That would be a cleaner way to do it, all right ... but for now, you can
> just reach in and set the indisprimary flag in pg_index after creating
> the index.  I'm visualizing
> 
<snip>
> 
> On the other hand, that would fall over if executed by a non-superuser.
> Drat.  Okay, I guess we just have to leave this as a TODO item for now.

This is one of those 'dual roles of pg_dump' problems: Philip has been
slowly migrating it from being a 'quickest possible backup dump' tool
to a 'recover my db in as human friendly (and SQL standards compliant)
a format as possible' tool.  Which, not coincidently, has dramatically
reduced the version fragility of the dump output.

Adding implementation specific performance hacks back in is probably
a necessary evil, but should probably be protected by a '--fastdump'
switch or some such.

Ross


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: pg_dump performance lossage for primary keys
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Final call for platform testing