On 12/8/14, 1:05 PM, Robert Haas wrote:
Besides, I haven't really seen anyone propose something that sounds like a credible alternative. If we could make partition objects things that the storage layer needs to know about but the query planner doesn't need to understand, that'd be maybe worth considering. But I don't see any way that that's remotely feasible. There are lots of places that we assume that a heap consists of blocks number 0 up through N: CTID pointers, index-to-heap pointers, nodeSeqScan, bits and pieces of the way index vacuuming is handled, which in turn bleeds into Hot Standby. You can't just decide that now block numbers are going to be replaced by some more complex structure, or even that they're now going to be nonlinear, without breaking a huge amount of stuff.
Agreed, but it's possible to keep a block/CTID interface while doing something different on the disk. If you think about it, partitioning is really a hack anyway. It clutters up your logical set implementation with a bunch of physical details. What most people really want when they implement partitioning is simply data locality. -- 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
