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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux