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 psql. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 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
