Re: On disable_cost

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-06-12 15:35:48
Message-ID: CA+Tgmoaow5wsubUvbn3GUosL6-opRG1Do5p8Q1Dj--OudUTWJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 7, 2024 at 4:19 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Here are some patches for discussion.

Well, that didn't generate much discussion, but here I am trying
again. Here I've got patches 0001 and 0002 from my previous posting;
I've dropped 0003 and 0004 from the previous set for now so as not to
distract from the main event, but they may still be a good idea.
Instead I've got an 0003 and an 0004 that implement the "count of
disabled nodes" approach that we have discussed previously. This seems
to work fine, unlike the approaches I tried earlier. I think this is
the right direction to go, but I'd like to know what concerns people
might have.

This doesn't completely remove disable_cost, because hash joins still
add it to the cost when it's impossible to fit the MCV value into
work_mem. I'm not sure what to do with that. Continuing to use
disable_cost in that one scenario seems OK to me. We could
alternatively make that scenario bump disabled_nodes, but I don't
really want to confuse the planner not wanting to do something with
the user telling the planner not to do something, so I don't think
that's a good idea. Or we could rejigger things so that in that case
we don't generate the plan at all. I'm not sure why we don't do that
already, actually.

--
Robert Haas
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
v2-0001-Remove-grotty-use-of-disable_cost-for-TID-scan-pl.patch application/octet-stream 8.4 KB
v2-0002-Rationalize-behavior-of-enable_indexscan-and-enab.patch application/octet-stream 13.1 KB
v2-0003-Treat-the-of-disabled-nodes-in-a-path-as-a-separa.patch application/octet-stream 70.8 KB
v2-0004-Show-the-of-disabled-nodes-in-EXPLAIN-ANALYZE-out.patch application/octet-stream 12.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-06-12 15:45:20 Re: Remove dependence on integer wrapping
Previous Message Jelte Fennema-Nio 2024-06-12 15:35:22 Re: RFC: adding pytest as a supported test framework