Re: On disable_cost

Alexander Law <exclusion@gmail.com>

From: Alexander Lakhin <exclusion@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-06T09:00:00Z
Lists: pgsql-hackers
Hello Robert,

21.08.2024 17:29, Robert Haas wrote:
> I went ahead and committed these patches. ...

Please take a look at the following code:
static void
label_sort_with_costsize(PlannerInfo *root, Sort *plan, double limit_tuples)
{
...
     cost_sort(&sort_path, root, NIL,
               lefttree->total_cost,
               plan->plan.disabled_nodes,
               lefttree->plan_rows,
               lefttree->plan_width,
               0.0,
               work_mem,
               limit_tuples);

Given the cost_sort() declaration:
void
cost_sort(Path *path, PlannerInfo *root,
           List *pathkeys, int input_disabled_nodes,
           Cost input_cost, double tuples, int width,
           Cost comparison_cost, int sort_mem,
           double limit_tuples)

Aren't the input_disabled_nodes and input_cost arguments swapped in the
above call?

(I've discovered this with UBSan, which complained
createplan.c:5457:6: runtime error: 4.40465e+09 is outside the range of representable values of type 'int'
while executing a query with a large estimated cost.)

Best regards,
Alexander



Commits

  1. Doc: add detail about EXPLAIN's "Disabled" property

  2. Adjust EXPLAIN's output for disabled nodes

  3. Fix order of parameters in a cost_sort call

  4. Show number of disabled nodes in EXPLAIN ANALYZE output.

  5. Treat number of disabled nodes in a path as a separate cost metric.

  6. Remove grotty use of disable_cost for TID scan plans.