Re: A problem about partitionwise join - Mailing list pgsql-hackers

From Richard Guo
Subject Re: A problem about partitionwise join
Date
Msg-id CAMbWs4-LyNkd_+wEFx6YVPJ_C8Jw-ThWYJM2_koFfTJw8R6RbA@mail.gmail.com
Whole thread Raw
In response to Re: A problem about partitionwise join  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On Wed, May 8, 2024 at 5:01 PM Richard Guo <guofenglinux@gmail.com> wrote:
> Below is what I got on my local machine.
>
> -- on master
>
>   measurement  | average  | maximum  | minimum  | std_dev | std_dev_as_perc_of_avg
> ---------------+----------+----------+----------+---------+------------------------
>  planning time | 30355.07 | 33148.47 | 29020.82 | 1681.23 | 5.54%
>
>
> -- on patched
>
>   measurement  | average  | maximum  | minimum  | std_dev | std_dev_as_perc_of_avg
> ---------------+----------+----------+----------+---------+------------------------
>  planning time | 30600.00 | 33523.23 | 28680.75 | 1861.90 | 6.08%
>
>
> -- without partitionwise join
>
>   measurement  | average | maximum | minimum | std_dev | std_dev_as_perc_of_avg
> ---------------+---------+---------+---------+---------+------------------------
>  planning time | 4840.18 | 5184.05 | 4528.87 | 299.98  | 6.20%
>
>
> So it seems that the planning time is not significantly affected by this
> patch, particularly when compared to the impact caused by partitionwise
> join.

This benchmark shows that the impact of this patch on planning time is
within the margin of error, particularly compared to the impact of
partitionwise joins.  So I've pushed this patch after working a bit
more on the commit message.

Thanks
Richard



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Is *fast* 32-bit support still important?
Next
From: Richard Guo
Date:
Subject: Re: Trivial revise for the check of parameterized partial paths