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

Поиск
Список
Период
Сортировка
От John Papandriopoulos
Тема Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Дата
Msg-id idd14l$a4u$1@news.hub.org
обсуждение исходный текст
Ответ на 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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On 12/3/10 10:20 PM, Tom Lane wrote:
> John Papandriopoulos<dr.jpap@gmail.com>  writes:
>> I've found that a k-ary table inheritance tree works quite well to
>> reduce the O(n) CHECK constraint overhead [1] in the query planner
>> when enabling partition constraint exclusion.
>
> Um ... you mean you're creating intermediate child tables for no reason
> except to reduce the number of direct descendants of any one table?
> That's an utter waste of time, because the first thing the planner will
> do with an inheritance tree is flatten it.  Just create *one* parent
> table and make all the leaf tables direct children of it.
>
>> My machine swaps wildly when PostgreSQL plans an UPDATE or DELETE.
>
> This is a strong hint that you've got way too many child tables.

Thanks for your advice, Tom.

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?  If I've way too many child tables, why isn't the SELECT query plan
causingthe same large memory usage? 

Kindest,
John


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Следующее
От: Markus Schulz
Дата:
Сообщение: Re: problem with from_collapse_limit and joined views