On Wed, Jul 5, 2023 at 9:45 PM Jakub Wartak <jakub.war...@enterprisedb.com>
wrote:
> [v3]
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -10,6 +10,7 @@
hard limits are reached.
</para>
+
<table id="limits-table">
@@ -92,11 +93,25 @@
<entry>can be increased by recompiling
<productname>PostgreSQL</productname></entry>
</row>
- <row>
- <entry>partition keys</entry>
- <entry>32</entry>
- <entry>can be increased by recompiling
<productname>PostgreSQL</productname></entry>
- </row>
+ <row>
+ <entry>partition keys</entry>
+ <entry>32</entry>
+ <entry>can be increased by recompiling
<productname>PostgreSQL</productname></entry>
+ </row>
Ahem.
> > Also, perhaps the LO entries should be split into a separate patch.
Since they are a special case and documented elsewhere, it's not clear
their limits fit well here. Maybe they could.
>
> Well, but those are *limits* of the engine and they seem to be pretty
widely chosen especially in migration scenarios (because they are the only
ones allowed to store over 1GB). I think we should warn the dangers of
using pg_largeobjects.
I see no argument here against splitting into a separate patch for later.
> > Also the shared counter is the cause of the slowdown, but not the
reason for the numeric limit.
>
> Isn't it both? typedef Oid is unsigned int = 2^32, and according to
GetNewOidWithIndex() logic if we exhaust the whole OID space it will hang
indefinitely which has the same semantics as "being impossible"/permanent
hang (?)
Looking again, I'm thinking the OID type size is more relevant for the
first paragraph, and the shared/global aspect is more relevant for the
second.
The last issue is how to separate the notes at the bottom, since there are
now two topics.
--
John Naylor
EDB: http://www.enterprisedb.com
