David Rowley <david.rowley@2ndquadrant.com> writes:
> [ v4-0001-Add-documentation-section-appendix-detailing-some.patch ]
A few nitpicky gripes on this -
* 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"?
* I think I'd make the title "PostgreSQL Limitations", as it
applies to the product not any one database.
* The repetition of "Maximum" in each table row seems rather
pointless; couldn't we just drop that word?
* 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.)
* 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.
* Many of these values are affected by BLCKSZ. How much effort
shall we spend on documenting that?
* Max ID length is 63 bytes not characters.
* 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.
* Ordering of the table entries seems a bit random.
> 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.
> It seems a bit arbitrarily set at the moment. I don't see
> any reason it couldn't be higher.
It's evidently intended to make sure varnos can fit in uint16.
Whether there's anyplace that's actually doing so, rather than
storing them as ints, I dunno.
regards, tom lane