Re: On disable_cost
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-05-06T13:39:38Z
Lists: pgsql-hackers
On Sat, May 4, 2024 at 12:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > There is also some weirdness around needing to force use of tidscan > if we have WHERE CURRENT OF. But perhaps a different hack could be > used for that. Yeah, figuring out what to do about this was the trickiest part of the experimental patch that I wrote last week. The idea of the current code is that cost_qual_eval_walker charges disable_cost for CurrentOfExpr, but cost_tidscan then subtracts disable_cost if tidquals contains a CurrentOfExpr, so that we effectively disable everything except TID scan paths and, I think, also any TID scan paths that don't use the CurrentOfExpr as a qual. I'm not entirely sure whether the last can happen, but I imagine that it might be possible if the cursor refers to a query that itself contains some other kind of TID qual. It's not very clear that this mechanism is actually 100% reliable, because we know it's possible in general for the costs of two paths to be different by more than disable_cost. Maybe that's not possible in this specific context, though: I'm not sure. The approach I took for my experimental patch was pretty grotty, and probably not quite complete, but basically I defined the case where we currently subtract out disable_cost as a "forced TID-scan". I passed around a Boolean called forcedTidScan which gets set to true if we discover that some plan is a forced TID-scan path, and then we discard any other paths and then only add other forced TID-scan paths after that point. There can be more than one, because of parameterization. But I think that the right thing to do is probably to pull some of the logic up out of create_tidscan_paths() and decide ONCE whether we're in a forced TID-scan situation or not. If we are, then set_plain_rel_pathlist() should arrange to create only forced TID-scan paths; otherwise, it should proceed as it does now. Maybe if I try to do that I'll find problems, but the current approach seems backwards to me, like going to a restaurant and ordering one of everything on the menu, then cancelling all of the orders except the stuff you actually want. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Doc: add detail about EXPLAIN's "Disabled" property
- 84b8fccbe5c2 18.0 landed
-
Adjust EXPLAIN's output for disabled nodes
- 161320b4b960 18.0 landed
-
Fix order of parameters in a cost_sort call
- 87b6c3c0b703 18.0 landed
-
Show number of disabled nodes in EXPLAIN ANALYZE output.
- c01743aa4866 18.0 landed
-
Treat number of disabled nodes in a path as a separate cost metric.
- e22253467942 18.0 landed
-
Remove grotty use of disable_cost for TID scan plans.
- e4326fbc60c4 18.0 landed