There's 2 problems: 1)
I recently noticed that EXPLAIN VERBOSE is a bit bogus when it comes to parallel aggregates with FILTER (WHERE ...) clauses. We get; Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0)))) FILTER (WHERE (num > 0)) Which is simply a lie, we only filter on the partial aggregate, not the combine. The attached patch just nullifies the combine aggregate's aggfilter clause during setrefs. We cannot nullify it any sooner, as the aggfilter is required so that we find the correct partial Aggref in search_indexed_tlist_for_partial_aggref(). With the attached we get; Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0)))) The patch is very simple. 2) I'm unsure if the schema prefix on the combine aggregate is a problem or not. The code path which generates it is rather unfortunate and is down to func_get_detail() returning FUNCDETAIL_NOTFOUND in generate_function_name() due to not being able to find a function named "sum" with the transtype as its only argument. I had thought that maybe we should add a pg_proc entry for the aggregate with the transtype, if not already covered by the entry for aggfnoid. Aggregates where the transtype is the same as the input type work just fine; Output: max((max(num))) The problem with that is adding the pg_proc entry still won't get rid of the schema as the "p_funcid == funcid" test in generate_function_name() will fail causing the schema qualification to occur again. But at least func_get_detail() would be successful in finding the function. Any one have any thoughts on if this is a problem? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
parallel_agg_filter_fix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
