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 B668B9DC810 for ; Thu, 2 Feb 2006 08:44:21 -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 33291-07 for ; Thu, 2 Feb 2006 08:44:23 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (serval.logix-tt.com [213.239.221.42]) by postgresql.org (Postfix) with ESMTP id 27C569DCDE4 for ; Thu, 2 Feb 2006 08:44:18 -0400 (AST) Received: from kingfisher.intern.logix-tt.com (Md470.m.pppool.de [89.49.212.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id 977FD24400F; Thu, 2 Feb 2006 13:44:23 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 1AD89181C209A; Thu, 2 Feb 2006 13:44:24 +0100 (CET) Message-ID: <43E1FEA7.8060509@logix-tt.com> Date: Thu, 02 Feb 2006 13:44:23 +0100 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en 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> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.127 required=5 tests=[AWL=0.127] X-Spam-Score: 0.127 X-Spam-Level: X-Archive-Number: 200602/39 X-Sequence-Number: 17025 Hi, Marc, Marc Morin wrote: > 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). Apart from having two separate views (one for report, one for insert) as Richard suggested: If you have fixed times for #3, don't start any #1 that won't finish before it's time for #3. You could also use the LOCK command on an empty lock table at the beginning of each #1 or #3 transaction to prevent #3 from getting the view lock before #1 is finished. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org