From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sorting table columns |
Date: | 2011-12-21 13:42:24 |
Message-ID: | 1324474753-sup-7426@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Simon Riggs's message of mié dic 21 09:44:04 -0300 2011:
> 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...
Great ideas. This one I'm not sure about at all:
> * "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.
Well, for the patch I'm working on right now, I'm just going to store an
ID as "physical representation", which will mean the sort order used for
the on-disk representation of our current heap storage; the idea here is
to allow columns to be sorted internally by the system so that alignment
padding is reduced; nothing more. Of course, we can work on more
complex representations later that allow different storage strategies,
such as the ones you propose.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-12-21 13:46:33 | Re: Extensions and 9.2 |
Previous Message | Simon Riggs | 2011-12-21 12:44:04 | Re: sorting table columns |