Re: GSets: Fix bug involving GROUPING and HAVING together - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: GSets: Fix bug involving GROUPING and HAVING together
Date
Msg-id 874mkt3l59.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: GSets: Fix bug involving GROUPING and HAVING together  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: GSets: Fix bug involving GROUPING and HAVING together
Re: GSets: Fix bug involving GROUPING and HAVING together
List pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> The other is that in subquery_planner, the optimization of
 Andrew> converting HAVING clauses to WHERE clauses is suppressed if
 Andrew> parse->groupingSets isn't empty. (It is empty if there's either
 Andrew> no group by clause at all, or if there's exactly one grouping
 Andrew> set, which must not be empty, however derived.) This is costing
 Andrew> us some optimizations, especially in the case of an explicit
 Andrew> GROUP BY () clause; I'll look into this.

I'm inclined to go with the simplest approach here, which copies the
quals if there are grouping sets. The only way we could safely move a
qual without copying is if we can show that none of the grouping sets is
empty, that is (), and at this point the grouping set list has not been
expanded so it's not trivial to determine that.

Patch attached.

--
Andrew (irc:RhodiumToad)


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Free indexed_tlist memory explicitly within set_plan_refs()
Next
From: Pavan Deolasee
Date:
Subject: Re: Reduce ProcArrayLock contention