On Tue, Dec 10, 2019 at 12:25:46AM +0100, Tomas Vondra wrote:
> >Everyone knows if you see a index scan is being used but is taking
> >longer than a sequential scan then you might try raising
> >random_page_cost. But I rarely see people tweaking the more "exotic"
> >parameters like operator_tuple_cost or index_tuple_cost and when they
> >do they aren't really sure what nodes they're affecting...
> >
>
> Well, but that's kinda my point - how would you know that you need to
> increase random_page_cost, or how big influence it has? The total is a
> fairly non-trivial combination of various cost parameters, effective
> cache size etc. Maybe I just don't understand how the cost is split into
> those pieces, named the same as the cost GUCs ...
Everything which right now does:
|cost += something*random_page_cost
..ends up (via a macro):
cost.random_page_cost += random_page_cost
And everything which does:
|cost1 += cost2
..ends up doing the same for each of the component members.
99% of this falls into place trivially.
I'm attaching a patch which is perhaps 95% working; various plans have changed,
so I gather there's at least a few bugs.
There's probably a few things which could be improved:
Probably some "Costs" should be simple doubles if they're only ever multiples
of a single cost parameter.
Maybe someone will say that Cost should be a typedef to a struct* rather than a struct.
Maybe I should get rid of cost_islt/isgt and just use cost_asscalar().
Seems like parallel_setup_cost and disable_cost could be booleans.
Justin
