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

Re: Column reordering in pg_dump

From: Decibel! <decibel(at)decibel(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "hernan gonzalez" <hgonzalez(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Column reordering in pg_dump
Date: 2008-11-26 19:32:53
Message-ID: 5B520153-8D8B-4008-9489-B2A4D3A5AC83@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Nov 25, 2008, at 9:41 PM, Robert Haas wrote:
>> Changing physical positioning is purely an internal matter.  A  
>> first-cut
>> implementation should probably just make it identical to logical
>> positioning, until the latter is changed by the user (after which,
>> physical positioning continues to reflect the original ordering).   
>> Only
>> after this work has been done and gotten battle-tested, we can get  
>> into
>> niceties like having the server automatically rearrange physical
>> positioning to improve performance.
>
> Yeah.  The problem with that is that, as Tom pointed out in a previous
> iteration of this discussion, you will likely have lurking bugs.  The
> bugs are going to come from confusing physical vs. logical vs. column
> identity, and if some of those are always-equal, it's gonna be pretty
> hard to know if you have bugs that confuse the two.  Now, if you could
> run the regression tests with a special option that would randomly
> permute the two orderings with respect to one another, that would give
> you at least some degree of confidence...


Random is good, but I suspect there are some boundary cases that  
could be tested too.

As for the complexity, it might make sense to only tackle part of  
this at a time. There would be value in only allowing logical order  
to differ from literal order, or only allowing physical order to  
differ. That means you could tackle just one of those for the first  
go-round and still get a benefit from it.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828



In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-11-26 19:47:05
Subject: Re: Simple postgresql.conf wizard
Previous:From: Guillaume SmetDate: 2008-11-26 19:27:19
Subject: Re: [bugfix] DISCARD ALL does not release advisory locks

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