On Tue, Nov 6, 2018 at 6:01 AM John Naylor <jcnaylor@gmail.com> wrote:
> On 11/1/18, David Rowley <david.rowley@2ndquadrant.com> wrote:
> > I've attached an updated patch, again it's just intended as an aid for
> > discussions at this stage. Also included the rendered html.
>
> Looks good so far. Based on experimentation with toasted columns, it
> seems the largest row size is 452GB, but I haven't tried that on my
> laptop. :-) As for the number-of-column limits, it's a matter of how
> much detail we want to include. With all the numbers in my previous
> email, that could probably use its own table if we include them all.
There are a lot of variables here. A particular row size may work for
one encoding and not for another.
IMHO, documenting that you can get up to 1600 integer columns but only
1002 bigint columns doesn't really help anybody, because nobody has a
table with only one type of column, and people usually want to have
some latitude to run ALTER TABLE commands later.
It might be useful for some users to explain that certain things will
should work for values < X, may work for values between X and Y, and
will definitely not work above Y. Or maybe we can provide a narrative
explanation rather than just a table of numbers. Or both. But I
think trying to provide a table of exact cutoffs is sort of like
tilting at windmills.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company