On Tue, Dec 20, 2011 at 9:47 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>> > The idea described there by Tom, and upon which I formed a vague
>> > implementation plan in my head, is that I was to look for all uses of
>> > an "attnum", and then replace it by either "attlognum" (i.e. the
>> > user-visible sort identifier) or "attphysnum" (i.e. the order of
>> > attributes as stored on disk).
>>
>> I thought we'd concluded that we really need three values: attnum should
>> be a permanent logical ID for each column, and then the user-visible
>> column order would be determined by a different number, and the on-disk
>> column order by a third. If we're going to do this at all, it seems
>> like a seriously bad idea to only go halfway, because then we'll just
>> have to revisit all the same code again later.
>
> Yeah, I was unclear -- that's what I'm doing (or, rather, attempting to
> do).
Sounds great.
While you're doing this, I'd like to think about future requirements,
to see if that changes anything.
Having a unique logical column id is a great thing because it allows
the physical storage to differ. This is the first part to allowing
these features...
* "column-based storage" where the data for some column(s) lives in a
dedicated heap
* "vertical partitioning" where defined groups of columns live in
separate heaps for performance and/or security
* "generated columns" where the column exists only logically and is
derived at run-time (per SQL Standard)
* "key/value columns" where we retrieve the column value from an hstore
* "very large number of columns" for statistical data sets where we
automatically vertically partition the heap when faced with large
numbers of column definitions
So when you store the physical representation please also store a
storage method, that currently has just one method SM_HEAP and a
relfilenode.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
