| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(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 18:53:20 |
| Message-ID: | CA+U5nMKAWG8fJ8uq23QPbFHrLsYqB4P_FWYmKxHS6xZ0NfxU7g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 21, 2011 at 1:42 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> 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
We currently have pg_attribute.attnum as an int2, so we can store up
to 32768 columns without changing that size, as long as we have some
place to put the data.
Was there something you're working on likely to preventing >240 cols?
Just worth documenting what you see at this stage.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2011-12-21 18:59:26 | Re: bghinter process |
| Previous Message | Robert Haas | 2011-12-21 18:47:13 | Re: bghinter process |