From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | David Christensen <david+pg(at)pgguru(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids) |
Date: | 2024-07-01 05:55:56 |
Message-ID: | CAExHW5tgxooDjYSWtRfNf9qF5VjXj_EtxHn5WorHjUtm4eHR1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 12, 2024 at 4:22 AM David Christensen <david+pg(at)pgguru(dot)net>
wrote:
> On Mon, Jun 10, 2024 at 8:15 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Mon, Jun 10, 2024 at 3:09 AM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > > This is just one instance of measurements. If I run the experiment
> multiple times the results and the patterns will vary. Usually I have found
> planning time to vary within 5% for regular tables and within 9% for
> partitioned tables with a large number of partitions. Below are
> measurements with the experiment repeated multiple times. For a given
> number of partitioned tables (each with 1000 partitions) being joined,
> planning time is measured 10 consecutive times. For this set of 10 runs we
> calculate average and standard deviation of planning time. Such 10 sets are
> sampled. This means planning time is sampled 100 times in total with and
> without patch respectively. Measurements with master and patched are
> reported in the attached excel sheet.
> >
> > Well, this is fine then I guess, but if the original results weren't
> > stable enough for people to draw conclusions from, then it's better
> > not to post them, and instead do this work to get results that are
> > stable before posting.
>
> Just doing a quick code review of the structure and the caller, I'd
> agree that this is properly hoisting the invariant, so don't see that
> it should contribute to any performance regressions. To the extent
> that it's called multiple times I can see that it's an improvement,
> with minimal code shuffling it seems like a sensible change (even in
> the single-caller case).
>
> In short +1 from me.
>
Hi David,
Do you think it needs more review or we can change it to "ready for
committer"?
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2024-07-01 06:04:06 | Optimize numeric multiplication for one and two base-NBASE digit multiplicands. |
Previous Message | Fujii Masao | 2024-07-01 05:54:56 | Assertion failure with summarize_wal enabled during pg_createsubscriber |