First, it would absolutely be best if we just got the full blown patch
into 8.3 and were done with it. I don't think anyone's arguing against
that... it's a question of what we can do if that can't happen (and it
does sound like the patch lost it's maintainer when the direction
changed towards doing both physical and logical ordering code at the
same time).

On Fri, Feb 23, 2007 at 01:04:14PM -0300, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > On Fri, Feb 23, 2007 at 02:09:55PM +0000, Simon Riggs wrote:
> > > > If you really want an interim solution, what about a builtin function 
> > > > that would explicitly mutate the definition and table contents (if any) 
> > > > along the lines you want? (assuming that's lots less work than just 
> > > > doing the whole thing right to start with). Or even one which just 
> > > > *displayed* the optimal order might be sufficient assistance to DBAs 
> > > > who 
> > > > want to take advantage of this.
> > > 
> > > I think the only interim solution now is to put functionality into
> > > PgAdmin et al to optimize the column order.
> > 
> > Well, if it comes to that it would be good to have pgAdmin et all driven
> > by logic in the database, so that people using psql can benefit as well.
> > Perhaps a function that is passed an existing table and re-creates it in
> > optimal order (if it's empty...). Or at least spits out a CREATE TABLE
> > statement for you that's in optimal order.
> That's just working around the fact that the engine is not smart enough
> to do the right thing (semi-) automatically.  We don't support that kind
> of operation, just like we don't support optimizer hints.

Except it's kind of the opposite... in this case, the database actually
knows better about what fields have what alignment, etc. At least if
users can get what the database says will be the best order they can use
that should they choose to.

I also don't see why we should restrict that information to users of
pgAdmin or other 3rd party tools and not support those that just use
Jim Nasby                                            [EMAIL PROTECTED]
EnterpriseDB      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to