Re: Fix for gistchoose - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Fix for gistchoose
Date
Msg-id CA+TgmoZHdruFmVEgVB6i8WqrtOsbyCPrZ9D3iDH7zJb87TO9XA@mail.gmail.com
Whole thread Raw
In response to Re: Fix for gistchoose  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Aug 30, 2012 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Aug 30, 2012 at 4:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yeah, the idea of replacing sum_grow with a boolean just occurred to me
>>> too.  As is, I think the code is making some less-than-portable
>>> assumptions about what will happen if sum_grow overflows; which can
>>> definitely happen, seeing that gistpenalty and its callees intentionally
>>> return infinity in some cases.  I'd rather it didn't attempt to add
>>> column penalties together, and I think there's a case to be made that
>>> not doing so is a back-patchable bug fix.
>
>> Keep in mind that the worst case outcome is the index quality is worse
>> than it otherwise would have been, so it's not like
>> OMG-PostgreSQ-eats-your-data.
>
> Agreed, but we've seen plenty of complaining about bloated gist indexes,
> and this might be the cause.

More likely one of several, but sure.

>>> I'll take a shot at improving this some more.
>
>> Okey dokey.
>
> Attached is a revised version of gistchoose(); I've not yet transposed
> the changes into gistRelocateBuildBuffersOnSplit().  It looks a lot
> more readable to me now.  Objections?

Looks good to me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Joe Abbate
Date:
Subject: Re: 9.2rc1 build requirements
Next
From: Bruce Momjian
Date:
Subject: Re: libpq compression