Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

On Wed, Jul 5, 2023 at 9:45 PM Jakub Wartak <jakub.wartak@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