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 70DD1531FE for ; Sun, 3 Apr 2005 13:01:39 +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 38160-06 for ; Sun, 3 Apr 2005 12:01:30 +0000 (GMT) Received: from wolff.to (wolff.to [66.93.249.74]) by svr1.postgresql.org (Postfix) with SMTP id AA5905332A for ; Sun, 3 Apr 2005 13:01:29 +0100 (BST) Received: (qmail 28048 invoked by uid 500); 3 Apr 2005 12:18:20 -0000 Date: Sun, 3 Apr 2005 07:18:20 -0500 From: Bruno Wolff III To: Karim A Nassar Cc: Simon Riggs , Stephan Szabo , Tom Lane , Christopher Kings-Lynne , pgsql-performance@postgresql.org Subject: Re: Delete query takes exorbitant amount of time Message-ID: <20050403121820.GB27923@wolff.to> Mail-Followup-To: Bruno Wolff III , Karim A Nassar , Simon Riggs , Stephan Szabo , Tom Lane , Christopher Kings-Lynne , pgsql-performance@postgresql.org References: <1112044045.11750.919.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.01 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200504/40 X-Sequence-Number: 11437 On Tue, Mar 29, 2005 at 01:48:48 -0700, Karim A Nassar wrote: > > For this FK check, there only need be one referring id to invalidate the > delete. ISTM that for any delete with a FK reference, the index could > always be used to search for a single value in the referring table > (excepting very small tables). Why then must a sequential scan be > performed in this case, and/or in general? First the index needs to exist. It isn't created automatically because not everyone wants such an index. Second, you need to have analyzed the referencing table so that the planner will know it is big enough that using an indexed search is worthwhile. The planner is getting better about dealing with size changes without reanalyzing, but it seems there are still some gotchas in 8.0.