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