Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Date
Msg-id dd256d54-f4f1-afc2-8a8d-9ab6b6515f7b@BlueTreble.com
Whole thread Raw
In response to Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 5/10/16 4:12 PM, Andres Freund wrote:
> The catalog representation (as in pg_class.reltoastrelid) isn't entirely
> clear to me.  One way would be to invert pg_class.reltoastrelid's
> meaning and have the toast table point to the table it stores values
> for. That'd also open the potential of having one toast table per column
> and such.

FWIW, toast-per-column is something I have a use case for.

Can we also consider using a per-toast-table sequence instead of OID? 
IIRC the generation mechanics of the two are similar, and that would 
greatly reduce the pressure on OID generation.

Tom, were you around when sequences were added? I'm guessing that that 
was done in response to OIDs becoming a serious problem in user tables 
on larger installs; ISTM this is just the next iteration of them being a 
problem. (And I suspect the one after this will be pg_attribute or maybe 
pg_depend).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Bug in intarray bench script
Next
From: David Fetter
Date:
Subject: Re: 10.0