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
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= |