| 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: | Whole Thread | Raw Message | 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 |