On Thu, Oct 26, 2023 at 04:17:19PM -0700, David G. Johnston wrote:
> On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston <david.g.johns...@gmail.com>
> wrote:
> 
>     On Thu, Oct 26, 2023 at 4:08 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> 
>         Bruce Momjian <br...@momjian.us> writes:
>         > Ah, I was confused.  I documented both in the attached patch.
> 
>         The function one should have the same annotation as some others:
> 
>              <entry>can be increased by recompiling <productname>PostgreSQL</
>         productname></entry>
> 
> 
> 
>     I'd like to see a comment on the parameter count one too.
> 
>     "Alternatives include using a temporary table or passing them in as a
>     single array parameter."
> 
>     About the only time this is likely to come up is with many parameters of
>     the same type and meaning, pointing that out with the array option seems
>     excessively wordy for the comment area.
> 
>     Needs a comma: 65,535
> 
>     Kinda think both should be tacked on to the end of the table.  I'd also 
> put
>     function arguments first so it appears under the compile time partition
>     keys limit.
> 
> 
> 
> Cleanups for consistency:
> 
> Move "identifier length" after "partition keys" (before the new "function
> arguments")
> 
> Add commas to: 1,600 and 1,664 and 8,192

Okay, I made all the suggested changes in ordering and adding commas,
plus the text about the ability to change function arguments via
recompiling.

I didn't put commas in 8192 since that is a power-of-two and kind of a
magic number used in many places.

I am not sure where to put text about using arrays to handle many
function arguments.  I just don't see it fitting in the table, or the
paragraph below the table.

Patch attached.

-- 
  Bruce Momjian  <br...@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index d5b2b627dd..c549447013 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -57,14 +57,14 @@
 
     <row>
      <entry>columns per table</entry>
-     <entry>1600</entry>
+     <entry>1,600</entry>
      <entry>further limited by tuple size fitting on a single page; see note
      below</entry>
     </row>
 
     <row>
      <entry>columns in a result set</entry>
-     <entry>1664</entry>
+     <entry>1,664</entry>
      <entry></entry>
     </row>
 
@@ -74,12 +74,6 @@
      <entry></entry>
     </row>
 
-    <row>
-     <entry>identifier length</entry>
-     <entry>63 bytes</entry>
-     <entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
-    </row>
-
     <row>
      <entry>indexes per table</entry>
      <entry>unlimited</entry>
@@ -92,11 +86,29 @@
      <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>
+
+    <row>
+     <entry>identifier length</entry>
+     <entry>63 bytes</entry>
+     <entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
+    </row>
+
+    <row>
+     <entry>function arguments</entry>
+     <entry>100</entry>
+     <entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
+    </row>
+
+    <row>
+     <entry>query parameters</entry>
+     <entry>65,535</entry>
+     <entry></entry>
+    </row>
    </tbody>
   </tgroup>
  </table>
@@ -104,9 +116,9 @@
  <para>
   The maximum number of columns for a table is further reduced as the tuple
   being stored must fit in a single 8192-byte heap page.  For example,
-  excluding the tuple header, a tuple made up of 1600 <type>int</type> columns
+  excluding the tuple header, a tuple made up of 1,600 <type>int</type> columns
   would consume 6400 bytes and could be stored in a heap page, but a tuple of
-  1600 <type>bigint</type> columns would consume 12800 bytes and would
+  1,600 <type>bigint</type> columns would consume 12800 bytes and would
   therefore not fit inside a heap page.
   Variable-length fields of
   types such as <type>text</type>, <type>varchar</type>, and <type>char</type>

Reply via email to