Message-ID: <4D23AAD6.8020700@agliodbs.com>
Date: Tue, 04 Jan 2011 15:18:46 -0800
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: Fixing GIN for empty/null/full-scan cases
References: <15190.1294175357@sss.pgh.pa.us>
	<AANLkTimSzna-1tkQkWoBJUegkG4xNP3QvLR3vKtyNBA3@mail.gmail.com>
	<15816.1294177767@sss.pgh.pa.us>
In-Reply-To: <15816.1294177767@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/4/11 1:49 PM, Tom Lane wrote:
> I don't think it's really worth the trouble.  The GIN code has been
> broken for these types of queries since day one, and yet we've had only
> maybe half a dozen complaints about it.  Moreover there's no practical
> way to "avoid trying to use the index", since in many cases the fact
> that a query requires a full-index scan isn't determinable at plan time.

Actually, there's been a *lot* of complaining about the GIN issues.
It's just that most of that complaining doesn't reach -hackers.

The common pattern I've seen in our practice and on IRC is:

1) user has GiST indexes
2) user tries converting them to GIN
3) user gets "full index scan" errors
4) user switches back and gives up

I agree that backwards compatibility should not be a priority; it is
sufficient to tell users to reindex.  For one thing, anyone who *is*
using GIN presently will have written their application code to avoid
full index scans.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com