From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Subject: | Re: make add_paths_to_append_rel aware of startup cost |
Date: | 2023-09-15 07:15:24 |
Message-ID: | CAApHDvry0nSV62kAOH3iccvfPhGPLN0Q97+=b1RsDPXDz3=CiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 7 Sept 2023 at 04:37, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> Currently add_paths_to_append_rel overlooked the startup cost for creating
> append path, so it may have lost some optimization chances. After a glance,
> the following 4 identifiers can be impacted.
> - We shouldn't do the optimization if there are still more tables to join,
> the reason is similar to has_multiple_baserels(root) in
> set_subquery_pathlist. But the trouble here is we may inherit multiple
> levels to build an appendrel, so I have to keep the 'top_relids' all the
> time and compare it with PlannerInfo.all_baserels. If they are the same,
> then it is the case we want to optimize.
I think you've likely gone to the trouble of trying to determine if
there are any joins pending because you're considering using a cheap
startup path *instead* of the cheapest total path and you don't want
to do that when some join will cause all the rows to be read thus
making the plan more expensive if a cheap startup path was picked.
Instead of doing that, why don't you just create a completely new
AppendPath containing all the cheapest_startup_paths and add that to
the append rel. You can optimise this and only do it when
rel->consider_startup is true.
Does the attached do anything less than what your patch does?
David
Attachment | Content-Type | Size |
---|---|---|
consider_cheapest_startup_appendpath.patch | application/octet-stream | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Karina Litskevich | 2023-09-15 07:37:10 | Re: BufferUsage counters' values have changed |
Previous Message | Lepikhov Andrei | 2023-09-15 06:21:27 | Re: RFC: Logging plan of the running query |