Re: R: Field's position in Table

From: Tino Wildenhain <tino(at)wildenhain(dot)de>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Michael Gould <mgould(at)intermodalsoftwaresolutions(dot)net>, Pg General <pgsql-general(at)postgresql(dot)org>
Subject: Re: R: Field's position in Table
Date: 2009-08-25 15:28:46
Message-ID: 4A94032E.1050607@wildenhain.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera wrote:
> Michael Gould wrote:
...
>> doesn't need to look at the overflow page. I don't know if this is true or
>> not in PostGres. If it isn't then I'm not sure what difference it would
>> make other than allowing for "pretty" documentation.
>
> Postgres does not overflow pages. Tuples are stored wholly on a single
> page. If they don't fit, large attributes are stored in a separate
> table (the TOAST table) and only a pointer is kept in the main table.
> So reordering won't give you that benefit.
>
> The other difference it would make is that it'd open the door for
> optimizations like storing all fixed-length not nullable attributes
> together at the start of the tuple. That should give slightly better
> performance.
>
And which is quite easily done by:

BEGIN;
CREATE table reorder_footable AS
SELECT b,c,a
FROM footable;
DROP TABLE footable;
ALTER TABLE reorder_footable RENAME TO footable;
COMMIT;

yes of course this does not deal with FK correctly
so a lot more work would need to be done for a general
solution - but in some cases it should be all one needs
for the tuple optimization. I personally don't by the
prettyness argument for reordering columns since for
all practical use I prefer SELECT a,b,c over SELECT *

Regards
Tino

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Guy Helmer 2009-08-25 15:39:20 Re: Invalid memory alloc request
Previous Message Vick Khera 2009-08-25 15:22:47 Re: How to simulate crashes of PostgreSQL?