Re: On disable_cost - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: On disable_cost
Date
Msg-id CAGECzQR48f_3A2oNsJR-8n+Jhsd4hX187F+3r6fbB8203C0kQg@mail.gmail.com
Whole thread Raw
In response to Re: On disable_cost  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: On disable_cost
List pgsql-hackers
On Wed, 31 Jul 2024 at 18:23, Robert Haas <robertmhaas@gmail.com> wrote:
> - If we do commit 0002, I think it's a good idea to have the number of
> disabled nodes displayed even with COSTS OFF, because it's stable, and
> it's pretty useful to be able to see this in the regression output. I
> have found while working on this that I often need to adjust the .sql
> files to say EXPLAIN (COSTS ON) instead of EXPLAIN (COSTS OFF) in
> order to understand what's happening. Right now, there's no real
> alternative because costs aren't stable, but disabled-node counts
> should be stable, so I feel this would be a step forward. Apart from
> that, I also think it's good for features to have regression test
> coverage, and since we use COSTS OFF everywhere or at least nearly
> everywhere in the regression test, if we don't print out the disabled
> node counts when COSTS OFF is used, then we don't cover that case in
> our tests. Bummer.

Are the disabled node counts still expected to be stable even with
GEQO? If not, maybe we should have a way to turn them off after all.
Although I agree that always disabling them when COSTS OFF is set is
probably also undesirable. How about a new option, e.g. EXPLAIN
(DISABLED OFF)



pgsql-hackers by date:

Previous
From: Lakshmi Narayana Velayudam
Date:
Subject: Usage of ProcessConfigfile in SIGHUP_Handler
Next
From: Andreas Karlsson
Date:
Subject: Re: Some questions about PostgreSQL’s design.