On Tue, Dec 22, 2015 at 2:16 AM, Paul Ramsey <pram...@cleverelephant.ca> wrote: > Shouldn’t parallel aggregate come into play regardless of scan selectivity? > I know in PostGIS land there’s a lot of stuff like: > > SELECT ST_Union(geom) FROM t GROUP BY areacode; > > Basically, in the BI case, there’s often no filter at all. Hoping that’s > considered a prime case for parallel agg :)
Yes, the latest patch attached in the thread addresses this issue. But it still lacks of proper cost calculation and comparison with original aggregate cost. The parallel aggregate selects only when the number of groups should be at least less than 1/4 of rows that are getting selected. Otherwise, doing aggregation two times for more number of records leads to performance drop compared to original aggregate. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
