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 29662.1291580078@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Список pgsql-performance
I wrote:
> You could get rid of the memory growth, at the cost of a lot of
> tree-copying, by doing each child plan step in a discardable memory
> context.  I'm not sure that'd be a win for normal sizes of inheritance
> trees though --- you'd need to copy the querytree in and then copy the
> resulting plantree out again, for each child.  (Hm, but we're doing the
> front-end copy already ...)

That worked better than I thought it would --- see
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d1001a78ce612a16ea622b558f5fc2b68c45ab4c
I'm not intending to back-patch this, but it ought to apply cleanly to
9.0.x if you want it badly enough to carry a local patch.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Следующее
От: Rob Wultsch
Дата:
Сообщение: Group commit and commit delay/siblings