From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: GIN improvements part 1: additional information
Date: Fri, 04 Oct 2013 00:30:57 +0300
Message-ID: <524DE211.50501@vmware.com> (raw)
In-Reply-To: <CAPpHfds6BeB_woqrXWHE65y51GKURN-6mPv4jT68YHn0Do-bkg@mail.gmail.com>
References: <CAPpHfduxv-iL7aedwPW0W5fXrWGAKfxijWM63_hZujaCRxnmFQ@mail.gmail.com>
<CAPpHfduQrtC4B+MC9_z3QB8oJsK1Ws-H8ivEsy_cmDnfoJqkeQ@mail.gmail.com>
<CAPpHfdszEJhSynTPX6=tB3aKq1EA1JXpwx4xiFYM097K7PhQLA@mail.gmail.com>
<CAPpHfdu8=5spaS7c9mxwH7bNMDR6n378fZCv6c2Y3YM7iE5KiQ@mail.gmail.com>
<51CEA13C.8040103@vmware.com>
<CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com>
<20130923153554.GA9534@momjian.us>
<524DBAEA.9080908@vmware.com>
<CA+Tgmoa6HEh1iXUgQS3Hph8gN4OORuzWVW=g2vVD7U4445F6Nw@mail.gmail.com>
<CAPpHfdvapv35UzyW02Lqr-20v_+JJy5jaU2Kj=FFSEFULiZ54Q@mail.gmail.com>
<524DD696.1060004@vmware.com>
<CAPpHfds6BeB_woqrXWHE65y51GKURN-6mPv4jT68YHn0Do-bkg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hlinnakangas@vmware.com, aekorotkov@gmail.com, robertmhaas@gmail.com, bruce@momjian.us
Subject: Re: GIN improvements part 1: additional information
In-Reply-To: <524DE211.50501@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox