Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)
От | Ashutosh Bapat |
---|---|
Тема | Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids) |
Дата | |
Msg-id | CAExHW5vhyg357HsHRKZwRyUekDsQuaBjLDJWbVaxotb4L2qMwg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)
|
Список | pgsql-hackers |
On Thu, Jun 6, 2024 at 10:00 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jun 5, 2024 at 3:48 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> Here's planning time measurements.
> num_joins | master (ms) | patched (ms) | change in planning time (ms) | change in planning time
> -----------+-------------+--------------+------------------------------+---------------------------------------
> 2 | 187.86 | 177.27 | 10.59 | 5.64%
> 3 | 721.81 | 758.80 | -36.99 | -5.12%
> 4 | 2239.87 | 2236.19 | 3.68 | 0.16%
> 5 | 6830.86 | 7027.76 | -196.90 | -2.88%
I find these results concerning. Why should the planning time
sometimes go up? And why should it go up for odd numbers of joinrels
and down for even numbers of joinrels? I wonder if these results are
really correct, and if they are, I wonder what could account for such
odd behavior
Observations from spreadsheet
1. Differences in planning time with master or patched version are within standard deviation. The difference is both ways. Indicating that the patch doesn't affect planning time adversely.
2. If we just look at the 5-way join numbers, there are more +ve s in column E and sometimes higher than standard deviation. Indicating that the patch improves planning time when there are higher number of partitioned tables being joined.
3. If we just look at the 5-way join numbers, the patch seems to reduce the standard deviation (column B vs column D) indicating that the planning time is more stable and predictable with patched version.
3. There is no bias towards even or odd numbers of partitioned tables being joined.
Looking at the memory savings numbers reported earlier, the patch improves memory consumption of partitionwise join without adversely affecting planning time. It doesn't affect the code paths which do not use partitionwise join. That's overall net positive impact for relatively less code churn.
--
Best Wishes,
Ashutosh Bapat
Вложения
В списке pgsql-hackers по дате отправления: