Re: Patch: improve selectivity estimation for IN/NOT IN - Mailing list pgsql-hackers

From Daniele Varrazzo
Subject Re: Patch: improve selectivity estimation for IN/NOT IN
Date
Msg-id CA+mi_8ZNbGFANB97R8-FbjZDUVpjrVdN3gAL8MVftUix1+O4ew@mail.gmail.com
Whole thread Raw
In response to Re: Patch: improve selectivity estimation for IN/NOT IN  (Euler Taveira de Oliveira <euler@timbira.com>)
Responses Re: Patch: improve selectivity estimation for IN/NOT IN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Mar 4, 2012 at 1:44 PM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> On 04-03-2012 00:20, Daniele Varrazzo wrote:
>> It looks like you have grand plans for array estimation. My patch has
>> a much more modest scope, and I'm hoping it could be applied to
>> currently maintained PG versions, as I consider the currently produced
>> estimations a bug.
>>
> We don't normally add new features to stable branches unless it is a bug. In
> the optimizer case, planner regression is a bug (that this case is not).

Please note that we are talking about planning errors leading to
estimates of records in the millions instead of in the units, in
queries where all the elements are known (most common elements, with
the right stats, included in the query), even with a partial index
whose size could never physically contain all the estimated rows
screaming "something broken here!". So, it's not a regression as the
computation has always been broken, but I think it can be hardly
considered not a bug.

OTOH, I expect the decision of leaving things as they are could be
taken on the basis of the possibility that some program may stop
working in reaction of an altered query plan: I'm not going to argue
about this, although I feel it unlikely.

-- Daniele


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Collect frequency statistics for arrays
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG FETCH readahead