Re: Fwd: [GENERAL] 4B row limit for CLOB tables

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: José Luis Tallón <jltallon(at)adv-solutions(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, 'Bruce Momjian' <bruce(at)momjian(dot)us>
Subject: Re: Fwd: [GENERAL] 4B row limit for CLOB tables
Date: 2015-04-28 17:48:33
Message-ID: 553FC7F1.8070401@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 4/28/15 5:41 AM, José Luis Tallón wrote:
> On 04/27/2015 08:49 AM, Jim Nasby wrote:
>> On 4/25/15 1:19 PM, Bruce Momjian wrote:
>>> Note if you are storing a table with rows that exceed 2KB in size
>>> (aggregate size of each row) then the "Maximum number of rows in a
>>> table" may be limited to 4 Billion, see TOAST.
>>
>> That's not accurate though; you could be limited to far less than 4B
>> rows. If each row has 10 fields that toast, you'd be limited to just
>> 400M rows.
>
> ISTM like the solution is almost here, and could be done without too
> much (additional) work:
> * We have already discussed having a page-per-sequence with the new
> SeqAMs being introduced and how that would improve scalability.
> * We have commented on having a sequence per TOAST table
> (hence, 4B toasted values per table each up to 4B chunks in size...
> vs just 4B toasted values per cluster)
>
> I'm not sure that I can do it all by myself just yet, but I sure
> can try if there is interest.

I don't think it would be hard at all to switch toast pointers to being
sequence generated instead of OIDs. The only potential downside I see is
the extra space required for all the sequnces... but that would only
matter on the tinyest of clusters (think embedded), which probably don't
have that many tables to begin with.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Evan Martin 2015-04-28 19:56:41 Re: Workaround for bug #13148 (deferred EXCLUDE constraint violation)
Previous Message John McKown 2015-04-28 12:16:46 Re: Workaround for bug #13148 (deferred EXCLUDE constraint violation)

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-04-28 17:53:38 Re: Freeze avoidance of very large table.
Previous Message Jim Nasby 2015-04-28 17:44:44 Re: PL/pgSQL, RAISE and error context