Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 156ED1337B8B for ; Sat, 4 Dec 2010 17:53:56 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 14508-08 for ; Sat, 4 Dec 2010 21:53:49 +0000 (UTC) Received: from news.hub.org (news.hub.org [200.46.204.72]) by mail.postgresql.org (Postfix) with ESMTP id 8DFA81337B54 for ; Sat, 4 Dec 2010 17:53:48 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.4/8.14.4) with ESMTP id oB4LrmVF020112 for ; Sat, 4 Dec 2010 17:53:48 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.4/8.14.4/Submit) id oB4LYTgN085375 for pgsql-performance@postgresql.org; Sat, 4 Dec 2010 17:34:29 -0400 (AST) (envelope-from news) From: John Papandriopoulos X-Newsgroups: pgsql.performance Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Date: Sat, 04 Dec 2010 13:34:28 -0800 Organization: Hub.Org Networking Services Lines: 45 Message-ID: References: <14012.1291443654@sss.pgh.pa.us> <23792.1291480923@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 In-Reply-To: <23792.1291480923@sss.pgh.pa.us> To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, T_RP_MATCHES_RCVD=-0.01, T_TO_NO_BRKTS_FREEMAIL=0.01 X-Spam-Level: X-Archive-Number: 201012/43 X-Sequence-Number: 41495 On 12/4/10 8:42 AM, Tom Lane wrote: > John Papandriopoulos 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. My example starts off with a new database (e.g. createdb ptest). I set up my schema using a machine generated SQL file [1] that simply creates a table create table ptest ( id integer ); and N = 0..4095 inherited children create table ptest_N ( check ( (id >= N_min) and (id <= N_max) ) ) inherits (ptest); that split the desired id::integer range into N buckets, one for each of the N partitions. I then immediately run a query-plan using EXPLAIN that exhibits the described behavior: super-fast plan for a SELECT statement, without swapping, and memory intensive (swapping) plans for DELETE and UPDATE. There are no triggers, no rules, no plpgsql functions, no indexes and no inserted data. Is there a more simple example that might help me convince you that we're exercising just the planner stage? Kindest, John [1] http://jpap.org/files/partition-test-flat.txt