Re: Improve planner cost estimations for alternative subplans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Improve planner cost estimations for alternative subplans
Дата
Msg-id 1853336.1592702279@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Improve planner cost estimations for alternative subplans  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Improve planner cost estimations for alternative subplans  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I'm not particularly familiar with AlternativeSubPlans, but I see we're
> picking the one in nodeSubplan.c based on plan_rows. Can't we do the
> same thing in cost_qual_eval_walker?

Nope.  The entire reason why we have that kluge is that we don't know
until much later how many times we expect to execute the subplan.
AlternativeSubPlan allows the decision which subplan form to use to be
postponed till runtime; but when we're doing things like estimating the
cost and selectivity of a where-clause, we don't know that.

Maybe there's some way to recast things to avoid that problem,
but I have little clue what it'd look like.

I agree that averaging together the costs of the alternatives seems
wrong in principle.  It's going to be one or the other, not some
quantum-mechanical superposition.  Maybe there's a case for taking the
min costs (if you're feeling lucky) or the max costs (if you're not),
on the belief that the executor will/will not pick the choice that
contributes least to the total query cost.  But I have a feeling that
either of those would distort our estimates too much.  The existing
costing behavior at least can be seen to match *one* actual runtime
behavior.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pg_regress cleans up tablespace twice.
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Operator class parameters and sgml docs