Re: Parallel Append implementation

On Thu, Aug 10, 2017 at 11:04 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> On 9 August 2017 at 19:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Jul 5, 2017 at 7:53 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
>>>> This is not applicable on the latest head i.e. commit --
>>>> 08aed6604de2e6a9f4d499818d7c641cbf5eb9f7, looks like need a rebasing.
>>>
>>> Thanks for notifying. Attached is the rebased version of the patch.
>>
>> This again needs a rebase.
>
> Attached rebased version of the patch. Thanks.
>

I tested this patch for partitioned TPC-H queries along with
partition-wise join patches [1]. The experimental setup used is as
follows,
Partitions were done on tables lineitem and orders and the partitioned
keys were l_orderkey and o_orderkey respectively. Range partitioning
scheme was used and the total number of partitions for each of the
tables was 17. These experiments are on scale factor 20. Server
parameters are kept as follows,
work_mem = 1GB
shared_buffers = 10GB
effective_cache_size = 10GB

All the values of time are in seconds

Query | Head | ParallelAppend + PWJ | Patches used by query
Q1 | 395 | 398 | only PA
Q3 | 130 | 90 | only PA
Q4 | 244 | 12 | PA and PWJ, time by only PWJ - 41
Q5 | 123 | 77 | PA only
Q6 | 29 | 12 | PA only
Q7 | 134 | 88 | PA only
Q9 | 1051 | 1135 | PA only
Q10 | 111 | 70 | PA and PWJ, time by only PWJ - 89
Q12 | 114 | 70 | PA and PWJ, time by only PWJ - 100
Q14 | 13 | 12 | PA only
Q18 | 508 | 489 | PA only
Q21 | 649 | 163 | PA only

To conclude, the patch is working good for the benchmark with no
serious cases of regression atleast at this scale factor and the
improvement in performance is significant. Please find the attached
file for the explain analyse output of the queries.

[1] CAFjFpRfy-YBL6AX3yeO30pAupTMQXgkxDc2P3XBK52QDzGtX5Q(at)mail(dot)gmail(dot)com

--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/