X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 871539DC857 for ; Wed, 1 Feb 2006 05:39:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 05003-07 for ; Wed, 1 Feb 2006 05:39:07 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 88B3B9DC837 for ; Wed, 1 Feb 2006 05:39:04 -0400 (AST) Received: from mainbox.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 3F7D3410EC9; Wed, 1 Feb 2006 09:39:06 +0000 (GMT) Received: from [192.168.1.17] (client17.office.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id F0A8415EA4; Wed, 1 Feb 2006 09:39:05 +0000 (GMT) Message-ID: <43E081B9.5050101@archonet.com> Date: Wed, 01 Feb 2006 09:39:05 +0000 From: Richard Huxton User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Marc Morin Cc: pgsql-performance@postgresql.org Subject: Re: partitioning and locking problems References: <2BCEB9A37A4D354AA276774EE13FB8C263B3DE@mailserver.sandvine.com> In-Reply-To: <2BCEB9A37A4D354AA276774EE13FB8C263B3DE@mailserver.sandvine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.115 required=5 tests=[AWL=0.115] X-Spam-Score: 0.115 X-Spam-Level: X-Archive-Number: 200602/9 X-Sequence-Number: 16995 Marc Morin wrote: > Under both these circumstances (truncate and create / replace rule) the > locking behaviour of these commands can cause locking problems for us. > The scenario is best illustrated as a series of steps: > > > 1- long running report is running on view > 2- continuous inserters into view into a table via a rule > 3- truncate or rule change occurs, taking an exclusive lock. > Must wait for #1 to finish. > 4- new reports and inserters must now wait for #3. > 5- now everyone is waiting for a single query in #1. Results > in loss of insert data granularity (important for our application). How much would you get from splitting the view into two: reporting and inserting? -- Richard Huxton Archonet Ltd