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

From Tom Lane
Subject Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Date
Msg-id 23792.1291480923@sss.pgh.pa.us
Whole thread Raw
In response to Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT  (John Papandriopoulos <dr.jpap@gmail.com>)
Responses 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  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
List 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 by date:

Previous
From: Віталій Тимчишин
Date:
Subject: Re: Slow query to get last created row using CURRVAL
Next
From: Tom Lane
Date:
Subject: Re: problem with from_collapse_limit and joined views