Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Дата
Msg-id 23792.1291480923@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT  (John Papandriopoulos <dr.jpap@gmail.com>)
Ответы Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Список pgsql-performance
Дерево обсуждения 
John Papandriopoulos <dr.jpap@gmail.com> writes:
> I've recreated the same example with just one parent table, and 4096 child tables.

> SELECT query planning is lightning fast as before; DELETE and UPDATE cause my machine to swap.

> What's different about DELETE and UPDATE here?

Hmm.  Rules?  Triggers?  You seem to be assuming the problem is at the
planner stage but I'm not sure you've proven that.

            regards, tom lane

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

Предыдущее
От: Віталій Тимчишин
Дата:
Сообщение: Re: Slow query to get last created row using CURRVAL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: problem with from_collapse_limit and joined views