From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Mikhail Balayan <mv(dot)balayan(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Subject: | Re: Planning time is time-consuming |
Date: | 2023-09-11 10:17:09 |
Message-ID: | CAApHDvog5X-fOcrR4y8EhK483MXM8d8ApXwevGBvPRg6azwqbg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 11 Sept 2023 at 21:54, Mikhail Balayan <mv(dot)balayan(at)gmail(dot)com> wrote:
> Could it be a regression? I'll check it on PG14 when I get a chance.
I'm not sure if you're asking for help here because you need planning
to be faster than it currently is, or if it's because you believe that
planning should always be faster than execution. If you think the
latter, then you're mistaken. It seems to me that the complexity of
planning this query is much more complex than executing it. The outer
side of the inner-most nested loop finds 0 rows, so it need not scan
the inner side, which results in that nested loop producing 0 rows,
therefore the outer side of none of the subsequent nested loops find
any rows. This is why you see "(never executed)" in the EXPLAIN
ANALYZE.
You could use perf record or perf top to dig into what's slow.
On the other hand, please report back if you find PG14 to be much faster here.
You could also experiment with a set of tables which are empty. It's
possible getting the relation sizes are a factor to consider here.
mdnblocks() needs to do a bit more work when the relation has multiple
segments.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Philippe Pepiot | 2023-09-11 12:21:30 | Re: Range partitioning query performance with date_trunc (vs timescaledb) |
Previous Message | David Rowley | 2023-09-11 08:24:35 | Re: Planning time is time-consuming |