Re: PostgreSQL Limits and lack of documentation about them.

Thanks for looking at this.

On Thu, 15 Nov 2018 at 13:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * I don't like inserting this as Appendix B, because that means
> renumbering appendixes that have had their same names for a *long*
> time; for instance the release notes have been Appendix E since
> we adopted the modern division of the docs in 7.4. So I'd put it
> below anything that's commonly-referenced. Maybe just before
> "Acronyms"?

Seems fair. I've pushed it down to before acronyms.

> * I think I'd make the title "PostgreSQL Limitations", as it
> applies to the product not any one database.

Changed.

> * The repetition of "Maximum" in each table row seems rather
> pointless; couldn't we just drop that word?

I've changed the column header to "Upper Limit" and removed the
"Maximum" in each row.

> * Items such as "relations per database" are surely not unlimited;
> that's bounded at 4G by the number of distinct OIDs. (In practice
> you'd get unhappy well before that, though I suppose that's true
> for many of these.)

True. I've changed this to 4,294,950,911, which is 2^32 -
FirstNormalObjectId - 1 (for InvalidOid)

> * Rows per table is also definitely finite if you are documenting
> pages per relation as finite. But it'd be worth pointing out that
> partitioning provides a way to surmount that.

I was unsure how best to word this one. I ended up with "Limited by
the number of tuples that can fit onto 4,294,967,295 pages"

> * Many of these values are affected by BLCKSZ. How much effort
> shall we spend on documenting that?

I've changed the comment in the maximum relation size to read
"Assuming the default BLCKSZ of 8192 bytes".

> * Max ID length is 63 bytes not characters.

Changed.

> * Don't think I'd bother with mentioning INCLUDE columns in the
> "maximum indexed columns" entry. Also, maybe call that "maximum
> columns per index"; as phrased, it could be misunderstood to
> mean that only 32 columns can be used in all indexes put together.

I slightly disagree about INCLUDE, but I've removed it anyway. Changed
the title to "Columns per index".

> * Ordering of the table entries seems a bit random.

It ended up that way due to me having not thought of any good order.
I've changed it to try to be roughly in order of scope; database
first, then things that go in them later. Perhaps that's no good, but
it does seem better than random. I don't really think alphabetical is
useful.

> > The only other thing that sprung to my mind was the maximum tables per
> > query. This is currently limited to 64999, not including double
> > counting partitioned tables and inheritance parents, but I kinda think
> > of we feel the need to document it, then we might as well just raise
> > the limit.
>
> Can't get excited about documenting that one ... although as things
> stand, it implies a limit on the number of partitions you can use
> that's way lower than the claimed 256M.

That is true, although that may change if we no longer reserve varnos
for pruned partitions. More partitions could then be created, you'd
just not be able to query them all at once. For now, I've just
removed the mention of maximum partitions as it seemed a little too
obscure to document the 64999 limit due to stepping into special varno
space.

Another thing that I was a bit unsure about is the maximum table size
limit. I've got written that it's 32 TB, but that's not quite correct
as it's 8192 bytes less than that due to InvalidBlockNumber. Writing
"35,184,372,080,640 bytes" did not seem like an improvement.

I also altered the intro paragraph to mention practical limitations
and that the table below only mentions hard limitations.

v5 is attached.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services