On 2/2/15 3:50 PM, José Luis Tallón wrote:
Hmm.... 2^32 times aprox. 2kB (as per usual heuristics, ~4 rows per heap page) is 8796093022208 (~9e13) bytes ... which results in 8192 1GB segments :O Looks like partitioning might be needed much sooner than that (if only for index efficiency reasons)... unless access is purely sequential.The problem with changing the id from 32 to 64 bits is that the storage *for everybody else* doubles, making the implementation slower for most.... though this might be actually not that important. 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.
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.
-- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
