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

From: Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fwd: [GENERAL] 4B row limit for CLOB tables
Date: 2015-04-26 14:44:26
Message-ID: 553CF9CA.7070004@8Kdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


On 25/04/15 06:39, Jim Nasby wrote:
> On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote:
>> On 24/04/15 05:24, Tom Lane wrote:
> ...
>>> TBH, I've got very little enthusiasm for fixing this given the number
>>> of reports of trouble from the field, which so far as I recall is zero.
>>> Álvaro's case came up through intentionally trying to create an
>>> unreasonable number of tables, not from real usage. This thread
>>> likewise
>>> appears to contain lots of speculation and no reports of anyone hitting
>>> a problem in practice.
>>
>> It is certainly true that this was a very synthetic case. I
>> envision, however, certain use cases where we may hit a very large
>> number of tables:
>
> The original case has NOTHING to do with the number of tables and
> everything to do with the number of toasted values a table can have.
> If you have to toast 4B attributes in a single relation it will fail.
> In reality, if you get anywhere close to that things will fall apart
> due to OID conflicts.
>
> This case isn't nearly as insane as 4B tables. A table storing 10 text
> fields each of which is 2K would hit this limit with only 400M rows.
> If my math is right that's only 8TB; certainly not anything insane
> space-wise or rowcount-wise.
>
> Perhaps it's still not fixing, but I think it's definitely worth
> documenting.

They are definitely different problems, but caused by similar
symptoms: an oid wrapping around, or not even there: just trying to find
an unused one. If fixed, we should probably look at both at the same time.

It's worth document but also, as I said, maybe also fixing them, so
that if three years from now they really show up, solution is already in
production (rather than in patching state).

Regards,

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message swaxolez 2015-04-26 15:52:02 Re: BDR Selective Replication
Previous Message Craig Ringer 2015-04-26 12:49:13 Re: BDR Selective Replication

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-04-26 14:53:28 pgsql: Add transforms feature
Previous Message Andrew Dunstan 2015-04-26 14:23:58 Re: forward vs backward slashes in msvc build code