Re: Patch: improve selectivity estimation for IN/NOT IN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: improve selectivity estimation for IN/NOT IN
Date: 2012-03-04 17:40:04
Message-ID: 16168.1330882804@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> On Sun, Mar 4, 2012 at 1:44 PM, Euler Taveira de Oliveira
> <euler(at)timbira(dot)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,

We're also talking about a proposed patch that is not clearly a bug fix,
but is a change in a heuristic, meaning it has the potential to make
things worse in some cases. (Notably, for arrays that *don't* contain
all-distinct values, the estimates are likely to get worse.) So I
wasn't thinking of it as being back-patchable anyway. It's generally
better not to destabilize planner behavior in minor releases, even if
it's a 90%-of-the-time improvement.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-03-04 18:08:18 Re: Command Triggers, patch v11
Previous Message Tom Lane 2012-03-04 17:34:22 Re: Our regex vs. POSIX on "longest match"