Re: GIN improvements part 1: additional information

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