|From:||Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>|
|To:||Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] Partition-wise aggregation/grouping|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Feb 13, 2018 at 6:21 PM, Jeevan Chalke <
> I see that partition-wise aggregate plan too uses parallel index, am I
> missing something?
You're right, I missed that, oops.
>> Q18 takes some 390 secs with patch and some 147 secs without it.
> This looks strange. This patch set does not touch parallel or seq scan as
> such. I am not sure why this is happening. All these three queries explain
> plan shows much higher execution time for parallel/seq scan.
> Yeah strange it is.
> However, do you see similar behaviour with patches applied,
> "enable_partition_wise_agg = on" and "enable_partition_wise_agg = off" ?
I tried that for query 18, with patch and enable_partition_wise_agg = off,
query completes in some 270 secs. You may find the explain analyse output
for it in the attached file. I noticed that on head the query plan had
parallel hash join however with patch and no partition-wise agg it is using
nested loop joins. This might be the issue.
> Also, does rest of the queries perform better with partition-wise
As far as this setting goes, there wasn't any other query using
partition-wise-agg, so, no.
BTW, just an FYI, this experiment is on scale factor 20.
|Next Message||Masahiko Sawada||2018-02-14 06:59:31||Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently|
|Previous Message||Ivan E. Panchenko||2018-02-14 06:29:33||Re: proposal: alternative psql commands quit and exit|