Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every |
Дата | |
Msg-id | 28056.1328723300@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every
|
Список | 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 по дате отправления: