Re: verbose cost estimate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Finnerty <jfinnert(at)amazon(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: verbose cost estimate
Date: 2019-12-09 16:20:57
Message-ID: 16856.1575908457@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Finnerty <jfinnert(at)amazon(dot)com> writes:
> +1, adding that sort of structure to Cost would get rejected out of hand.
> however, having a 'disabled' bit be part of the cost structure is something
> that I would support. This has been discussed previously, but even adding
> one bit to Cost doesn't have everyone's support. The purpose of a disabled
> bit would be to distinguish plans that had no disable_cost added to them
> from plans that did so that the planner can choose the minimum cost
> non-disabled plan, if any such plan exists, or choose the minimum cost plan
> otherwise. A disable count could be used, but even a bool would probably
> suffice.

If we did go that route, I think a disable count would be the right thing.
It wouldn't take up any more space than a bool, probably, once you account
for padding overhead. And the code impact in hotspots like add_path would
be just about the same too. The advantage of a count is that, for
example, if you have enable_seqscan off then a path containing three
seqscans could be considered inferior to one with two; but if we have
only a bool then we can't tell the difference.

(Having said that, I'm still about -0.5 or so on the idea. But if
we do it, we should do a count.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message rajesh kumar 2019-12-09 16:21:13 Re: ERROR: uncommitted xmin 347341220 from before xid cutoff 967029200 needs to be frozen
Previous Message Heikki Linnakangas 2019-12-09 16:13:13 Re: Questions about PostgreSQL implementation details