On Wed, Feb 8, 2012 at 19:48, Tom Lane wrote:
> I applied this patch, since I was busy applying catalog changes from you
> anyway ;-).
Thanks :)
> 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,
>
Marti Raudsepp writes:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp 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
On Thu, Dec 22, 2011 at 11:52 AM, Marti Raudsepp wrote:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp wrote:
>>> PS: It seems that the min/max optimization isn't documented in the
>>> manual (apart from release notes), so I didn't include
On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp 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 atta
On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp 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 t
Hi list,
As discussed on the pgsql-general list, the bool_and() and bool_or()
aggregate functions behave exactly like min() and max() would over
booleans. While it's not likely that people would have an appropriate
index on a boolean column, it seems it wouldn't cost us anything to
take advantage
