Re: Parallel Aggregate
От | Paul Ramsey |
---|---|
Тема | Re: Parallel Aggregate |
Дата | |
Msg-id | etPan.567817c3.6b8b4567.14f8e@Butterfly.local обсуждение исходный текст |
Ответ на | Re: Parallel Aggregate (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Ответы |
Re: Parallel Aggregate
Re: Parallel Aggregate |
Список | pgsql-hackers |
On December 21, 2015 at 2:33:56 AM, Haribabu Kommi (kommi.haribabu@gmail.com) wrote:
Yes the query is producing more groups according to the selectivity.
For example - scan selectivity - 400000, the number of groups - 400
Following is the query:
SELECT tenpoCord,
SUM(yokinZandaka) AS yokinZandakaxGOUKEI,
SUM(kashikoshiZandaka) AS kashikoshiZandakaxGOUKEI,
SUM(kouzasuu) AS kouzasuuxGOUKEI,
SUM(sougouKouzasuu) AS sougouKouzasuuxGOUKEI
FROM public.test01
WHERE tenpoCord <= '001' AND
kamokuCord = '01' AND
kouzaKatujyoutaiCord = '0'
GROUP BY kinkoCord,tenpoCord;
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 :)
P
В списке pgsql-hackers по дате отправления: