Marti Raudsepp <ma...@juffo.org> writes:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas <robertmh...@gmail.com> wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp <ma...@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);
\timing
explain 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
