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
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" |