Re: Planning time of Generic plan for a table partitioned into a lot

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Planning time of Generic plan for a table partitioned into a lot
Дата
Msg-id 81e3a1c2-80cb-3e3b-f4b2-441cd1d76df3@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Planning time of Generic plan for a table partitioned into a lot  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Planning time of Generic plan for a table partitioned into a lot  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2018/11/29 19:54, David Rowley wrote:
> The problem is only made worse in PG11 from PG10
> because generating the custom plan has become faster than it
> previously was due to the new partition pruning code which might make
> it appear we can handle more partitions than we could previously,
Actually, PG 11's pruning improvements don't change plancache.c's equation
of custom plan cost, that is, even if pruning may have gotten faster it
doesn't change the value cached_plan_cost comes up with.

Although, you're certainly right that users are well advised to trust the
documentation to not go beyond hundreds of partitions, even if they may
not care about all the internal details that make partitioning slow.

Thanks,
Amit



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pgsql: Add TAP tests for pg_verify_checksums
Следующее
От: "Yamaji, Ryo"
Дата:
Сообщение: RE: [HACKERS] Cached plans and statement generalization