From: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
---|---|
To: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns |
Date: | 2023-04-22 15:42:29 |
Message-ID: | CABwTF4XQavGEuRUWwkdEj7id-s2WszO1yWciS9oGFoyYqfwXVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 21, 2023 at 12:14 AM Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:
> This limitation applies not only to wide tables - it also applies to tables where TOASTed values
> are updated very often. You would soon be out of available TOAST value ID because in case of
> high frequency updates autovacuum cleanup rate won't keep up with the updates. It is discussed
> in [1].
>
> On Fri, Apr 21, 2023 at 9:39 AM Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>> I would like to ask if it wouldn't be good idea to copy the
>> https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit
>> discussion (out-of-line OID usage per TOAST-ed columns / potential
>> limitation) to the official "Appendix K. PostgreSQL Limits" with also
>> little bonus mentioning the "still searching for an unused OID in
>> relation" notice. Although it is pretty obvious information for some
>> and from commit 7fbcee1b2d5f1012c67942126881bd492e95077e and the
>> discussion in [1], I wonder if the information shouldn't be a little
>> more well known via the limitation (especially to steer people away
>> from designing very wide non-partitioned tables).
>>
>> [1] - https://www.postgresql.org/message-id/flat/16722-93043fb459a41073%40postgresql.org
>
> [1] https://www.postgresql.org/message-id/CAN-LCVPRvRzxeUdYdDCZ7UwZQs1NmZpqBUCd%3D%2BRdMPFTyt-bRQ%40mail.gmail.com
These 2 discussions show that it's a painful experience to run into
this problem, and that the hackers have ideas on how to fix it, but
those fixes haven't materialized for years. So I would say that, yes,
this info belongs in the hard-limits section, because who knows how
long it'll take this to be fixed.
Please submit a patch.
I anticipate that edits to Appendix K Postgres Limits will prompt
improving the note in there about the maximum column limit, That note
is too wordy, and sometimes confusing, especially for the audience
that it's written for: newcomers to Postgres ecosystem.
Best regards,
Gurjeet https://Gurje.et
http://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Isaac Morland | 2023-04-22 16:53:23 | Re: Mark a transaction uncommittable |
Previous Message | Tom Lane | 2023-04-22 15:37:08 | Re: run pgindent on a regular basis / scripted manner |