Re: logical column ordering

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical column ordering
Date: 2015-02-27 20:56:20
Message-ID: 54F0D9F4.4020608@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28/02/15 09:49, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> 1) change the order of columns in "SELECT *"
>>
>> - display columns so that related ones grouped together
>> (irrespectedly whether they were added later, etc.)
>>
>> - keep columns synced with COPY
>>
>> - requires user interface (ALTER TABLE _ ALTER COLUMN _ SET ORDER _)
> Not sure about the "ORDER #" syntax. In ALTER ENUM we have "AFTER
> <value>" and such .. I'd consider that instead.
>
>> 2) optimization of physical order (efficient storage / tuple deforming)
>>
>> - more efficient order for storage (deforming)
>>
>> - may be done manually by reordering columns in CREATE TABLE
>>
>> - should be done automatically (no user interface required)
> A large part of it can be done automatically: for instance, not-nullable
> fixed length types ought to come first, because that enables the
> attcacheoff optimizations in heaptuple.c to fire for more columns. But
> what column comes next? The offset of the column immediately after them
> can also be cached, and so it would be faster to obtain than other
> attributes. Which one to choose here is going to be a coin toss in most
> cases, but I suppose there are cases out there which can benefit from
> having a particular column there.
>
>
Possible, if there is no obvious (to the system) way of deciding the
order of 2 columns, then the logical order should be used?

As either the order does not really matter, or an expert DBA might know
which is more efficient.

Cheers,
Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-02-27 20:57:24 Re: plpgsql versus domains
Previous Message David Fetter 2015-02-27 20:54:19 Re: POLA violation with \c service=