On 03.10.2013 23:54, Alexander Korotkov wrote:
ItemPointers compression reduce occupied space in all normal cases. It's not very realistic, but it could increase space in worst case. That would lead to page split after conversion. Are we going to support such case?
Hmm, that's probably rare enough that the number of such indexes in the real world where that could happen is exactly 0. A compressed item requires 7 bytes in the worst case; that is an offset > 127, and distance to previous item > 2^(4*7) = 268435456 blocks. With the default block size, that requires an index larger than 2TB. And that's just for one such item to appear - to actually cause a page to overflow, a page would need to be full of other items widely apart each other to take up 6 bytes each.
So I think if you can make the conversion work with the assumption that the compressed format always fits in the old space, and throw an error if it doesn't, that's good enough. (That's for the posting trees - the posting lists attached to entry tuples is a different story.)
Besides, if you convert the page when you insert to it, you might need to split it anyway. So it might not be very difficult to split if required.
IMHO the main argument for not bothering with pg_upgrade is that the gain from the patch is so great that you'll want to REINDEX after the upgrade anyway, to shrink the index. I really don't have an opinion on whether we should attempt reading the old format. On one hand, it would be really nice to not have that caveat when you pg_upgrade (oh, you have GIN indexes, you have to reindex..). On the other hand, supporting the old format is a fair amount of extra code to maintain.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
