Re: 15x slower PreparedStatement vs raw query

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: 15x slower PreparedStatement vs raw query
Дата
Msg-id CAApHDvqMqwc2uf=pgeNq-iKn7StPXxczWxO=4-wTqW-vc2BxRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 15x slower PreparedStatement vs raw query  (Alex <cdalxndr@yahoo.com>)
Ответы Re: 15x slower PreparedStatement vs raw query  (Alex <cdalxndr@yahoo.com>)
Список pgsql-performance
On Tue, 4 May 2021 at 22:05, Alex <cdalxndr@yahoo.com> wrote:
> Shouldn't this process be automatic based on some heuristics?

When plan_cache_mode is set to "auto", then the decision to use a
generic or custom plan is cost-based. See [1]. There's a fairly crude
method there for estimating the effort required to replan the query.
The remainder is based on the average cost of the previous custom
plans + estimated planning effort vs cost of the generic plan.  The
cheaper one wins.

Certainly, what's there is far from perfect.  There are various
problems with it.  The estimated planning cost is pretty crude and
could do with an overhaul.   There are also issues with the plan costs
not being true to the cost of the query.  One problem there is that
run-time partition pruning is not costed into the plan.  This might
cause choose_custom_plan() to pick a custom plan when a generic one
with run-time pruning might have been better.

In order to get a better idea of where things are going wrong for you,
we'd need to see the EXPLAIN ANALYZE output for both the custom and
the generic plan.

David

[1] https://github.com/postgres/postgres/blob/master/src/backend/utils/cache/plancache.c#L1019



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

Предыдущее
От: Vijaykumar Jain
Дата:
Сообщение: Re: 15x slower PreparedStatement vs raw query
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: 15x slower PreparedStatement vs raw query