On 02/03/2015 03:44 AM, Jim Nasby wrote:
[snip]
The alternative could be some "long LOB" ("HugeOBject"?) using the
equivalent to "serial8" whereas regular LOBs would use "serial4".
Well, it depends on how we did this. We could (for example) add a
field to pg_class that determines what type to use for toast pointers;
OID, int, or bigint. That could then be taken into account in the
*toast* functions.
But as others have pointed out, we haven't even had any real
complaints about toast using OIDs as being an issue until now, so I
think it's premature to start messing with this. At most it's just
something to keep in mind so we don't preclude doing this in the future.
A patch creating those HOBs (Huge Objects) might well make sense *after*
the sequence refactoring got merged.
Removing the bottleneck due to the OID allocator for this use case will
be definitively welcome
(I don't dare to code that just yet, but here's hoping someone will
step in O:-)
BTW, regarding the size of what gets toasted; I've often thought it
would be useful to allow a custom size limit on columns so that you
could easily force data to be toasted if you knew you were very
unlikely to access it. Basically, a cheap form of vertical partitioning.
Hmmm.... alter column set storage external / set storage extended ?
From http://www.postgresql.org/docs/9.4/static/sql-altertable.html :
ALTER [ COLUMN ] column_name SET STORAGE { PLAIN | EXTERNAL |
EXTENDED | MAIN }
This would do what you described, right?
HTH,
/ J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
