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>
From: Robert Haas <robertmhaas@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: David Christensen <david+pg@pgguru.net>,
Richard Guo <guofenglinux@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-06-06T16:30:39Z
Lists: pgsql-hackers
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 -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Reduce memory used by partitionwise joins
- 513f4472a4a0 18.0 landed
-
Fix calculation of relid sets for partitionwise child joins.
- f75595cd80d1 16.0 landed
- 3c90dcd03914 17.0 landed