Re: Parallel Append implementation
Amit Khandekar <amitdkhan.pg@gmail.com>
From: Amit Khandekar <amitdkhan.pg@gmail.com>
To: Rafia Sabih <rafia.sabih@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-07T08:23:55Z
Lists: pgsql-hackers
On 7 September 2017 at 13:40, Rafia Sabih <rafia.sabih@enterprisedb.com> wrote: > On Wed, Aug 30, 2017 at 5:32 PM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: >> Hi Rafia, >> >> On 17 August 2017 at 14:12, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: >>> But for all of the cases here, partial >>> subplans seem possible, and so even on HEAD it executed Partial >>> Append. So between a Parallel Append having partial subplans and a >>> Partial Append having partial subplans , the cost difference would not >>> be significant. Even if we assume that Parallel Append was chosen >>> because its cost turned out to be a bit cheaper, the actual >>> performance gain seems quite large as compared to the expected cost >>> difference. So it might be even possible that the performance gain >>> might be due to some other reasons. I will investigate this, and the >>> other queries. >>> >> >> I ran all the queries that were showing performance benefits in your >> run. But for me, the ParallelAppend benefits are shown only for plans >> that use Partition-Wise-Join. >> >> For all the queries that use only PA plans but not PWJ plans, I got >> the exact same plan for HEAD as for PA+PWJ patch, except that for the >> later, the Append is a ParallelAppend. Whereas, for you, the plans >> have join-order changed. >> >> Regarding actual costs; consequtively, for me the actual-cost are more >> or less the same for HEAD and PA+PWJ. Whereas, for your runs, you have >> quite different costs naturally because the plans themselves are >> different on head versus PA+PWJ. >> >> My PA+PWJ plan outputs (and actual costs) match exactly what you get >> with PA+PWJ patch. But like I said, I get the same join order and same >> plans (and actual costs) for HEAD as well (except >> ParallelAppend=>Append). >> >> May be, if you have the latest HEAD code with your setup, you can >> yourself check some of the queries again to see if they are still >> seeing higher costs as compared to PA ? I suspect that some changes in >> latest code might be causing this discrepancy; because when I tested >> some of the explains with a HEAD-branch server running with your >> database, I got results matching PA figures. >> >> Attached is my explain-analyze outputs. >> > > Strange. Please let me know what was the commit-id you were > experimenting on. I think we need to investigate this a little > further. Sure. I think the commit was b5c75fec. It was sometime in Aug 30 when I ran the tests. But you may try on latest head. > Additionally I want to point that I also applied patch [1], > which I forgot to mention before. Yes , I also had applied that patch over PA+PWJ. > > [1] https://www.postgresql.org/message-id/CAEepm%3D3%3DNHHko3oOzpik%2BggLy17AO%2Bpx3rGYrg3x_x05%2BBr9-A%40mail.gmail.com -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
Commits
-
Update parallel.sgml for Parallel Append
- ac535cd47806 11.0 landed
- e80f2b335ecd 12.0 landed
-
Support Parallel Append plan nodes.
- ab7271677812 11.0 landed
-
Remove BufFile's isTemp flag.
- 11e264517dff 11.0 cited
-
Improve comments for parallel executor estimation functions.
- 11c1d555cebe 11.0 landed
-
Separate reinitialization of shared parallel-scan state from ExecReScan.
- 41b0dd987d44 11.0 cited
-
Eat XIDs more efficiently in recovery TAP test.
- 08aed6604de2 10.0 cited
-
Avoid syntax error on platforms that have neither LOCALE_T nor ICU.
- 457a44487328 10.0 cited
-
Preparatory refactoring for parallel merge join support.
- a71f10189dc1 10.0 cited