X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 66A4553659 for ; Tue, 29 Mar 2005 16:26:13 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 85476-04 for ; Tue, 29 Mar 2005 15:26:10 +0000 (GMT) Received: from cmailm4.svr.pol.co.uk (cmailm4.svr.pol.co.uk [195.92.193.211]) by svr1.postgresql.org (Postfix) with ESMTP id E8BDD533A2 for ; Tue, 29 Mar 2005 16:26:09 +0100 (BST) Received: from modem-2151.llama.dialup.pol.co.uk ([217.135.184.103] helo=192.168.0.102) by cmailm4.svr.pol.co.uk with esmtp (Exim 4.41) id 1DGIbW-00072J-Lv; Tue, 29 Mar 2005 16:26:07 +0100 Subject: Re: Delete query takes exorbitant amount of time From: Simon Riggs To: Tom Lane Cc: Stephan Szabo , Karim A Nassar , Christopher Kings-Lynne , pgsql-performance@postgresql.org In-Reply-To: <21616.1112108201@sss.pgh.pa.us> References: <1112095776.11750.958.camel@localhost.localdomain> <20050329054714.V50612@megazone.bigpanda.com> <20050329061837.A51620@megazone.bigpanda.com> <21616.1112108201@sss.pgh.pa.us> Content-Type: text/plain Organization: 2nd Quadrant Date: Tue, 29 Mar 2005 16:24:40 +0100 Message-Id: <1112109880.11750.977.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.048 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200503/634 X-Sequence-Number: 11339 On Tue, 2005-03-29 at 09:56 -0500, Tom Lane wrote: > Stephan Szabo writes: > > If there were some way to pass a "limit" into SPI_prepare that was treated > > similarly to a LIMIT clause for planning purposes but didn't actually > > change the output plan to only return that number of rows, we could use > > that. > > Hmm ... the planner does have the ability to do that sort of thing (we > use it for cursors). SPI_prepare doesn't expose the capability. > Perhaps adding a SPI_prepare variant that does expose it would be the > quickest route to a solution. > > I get a headache every time I look at the RI triggers ;-). Do they > always know at the time of preparing a plan which way it will be used? If action is NO ACTION or RESTRICT then we need to SELECT at most 1 row that matches the criteria which means we can use LIMIT 1 If action is CASCADE, SET NULL, SET DEFAULT then we need to UPDATE or DELETE all rows that match the criteria which means we musnt use LIMIT and need to use FOR UPDATE We know that at CONSTRAINT creation time, which always occurs before plan preparation time. Best Regards, Simon Riggs