| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) |
| Date: | 2016-05-17 14:38:28 |
| Message-ID: | dd256d54-f4f1-afc2-8a8d-9ab6b6515f7b@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2016-05-17 14:51:18 | Re: 10.0 |
| Previous Message | Daniel Gustafsson | 2016-05-17 09:18:17 | Bug in intarray bench script |