Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every
Date
Msg-id 28056.1328723300@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every  (Marti Raudsepp <marti@juffo.org>)
Responses Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every
List pgsql-hackers
Marti Raudsepp <marti@juffo.org> writes:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp <marti@juffo.org> wrote:
>>> PS: It seems that the min/max optimization isn't documented in the
>>> manual (apart from release notes), so I didn't include any doc changes
>>> in this patch.

>> I don't see a patch attached to this email, so either you forgot to
>> attach it, or the list ate it somehow.

> I forgot to attach it, sorry. Here it is.

I applied this patch, since I was busy applying catalog changes from you
anyway ;-).

I did think of a possible reason to reject the patch: with this change,
the planner will take longer to plan queries involving bool_and() et al,
since planagg.c will spend time looking (usually fruitlessly) for an
index-based plan.  I tried this simple test case:
create table t (f1 bool);\timingexplain select bool_and(f1) from t;

Best-case timings for the EXPLAIN were about 0.480 ms without the patch
and 0.500 ms with, so about a 4% penalty.  On more complicated queries
I think the fractional cost would be less.  This seemed acceptable to
me, so I went ahead and applied the change, but if anyone wants to
argue about it now's the time.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Text-any concatenation volatility acting as optimization barrier
Next
From: Tom Lane
Date:
Subject: Re: Text-any concatenation volatility acting as optimization barrier