Re: Should we add GUCs to allow partition pruning to be disabled?

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Should we add GUCs to allow partition pruning to be disabled?
Дата
Msg-id CAKJS1f-+ZcjvsLJHVOQQeGqFtvu63436ojVxHjPvECvJfmx51w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Should we add GUCs to allow partition pruning to be disabled?
Список pgsql-hackers
On Mon, 11 Mar 2019 at 15:00, David Rowley <david.rowley@2ndquadrant.com> wrote:
>
> On Mon, 11 Mar 2019 at 14:33, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> > PG 11 moved the needle a bit for SELECT queries:
> >
> > Excluding unnecessary partitions is slow for UPDATE and DELETE queries,
>
> With those words I expect the user might be surprised that it's still
> slow after doing SET enable_partition_pruning = off;

I had in mind in 10, 11 and master add a note to mention:

Currently, it is not recommended to have partition hierarchies more
than a few hundred partitions.  Larger partition hierarchies can
suffer from slow planning times with <command>SELECT</command>
queries.  Planning times for <command>UPDATE</command> and
<command>DELETE</command> commands may also suffer slow planning
times, but in addition, memory consumption may also become an issue
due to how the planner currently plans the query once per partition.
These limitations are likely to be resolved in a future version of
<productname>PostgreSQL</productname>.

I've not really thought too much on the fact that the issue also
exists with inheritance tables in earlier version too.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: Pluggable Storage - Andres's take