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 966E85334D for ; Fri, 25 Mar 2005 21:25:25 +0000 (GMT) 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 67462-07 for ; Fri, 25 Mar 2005 21:25:23 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 5EFB55335F for ; Fri, 25 Mar 2005 21:25:22 +0000 (GMT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j2PLP9fA012832; Fri, 25 Mar 2005 16:25:09 -0500 (EST) To: Stephan Szabo Cc: Simon Riggs , Karim Nassar , Christopher Kings-Lynne , pgsql-performance@postgresql.org Subject: Re: Delete query takes exorbitant amount of time In-reply-to: <20050325130124.U15470@megazone.bigpanda.com> References: <1111709457.9085.127.camel@k2.cet.nau.edu> <2630.1111711927@sss.pgh.pa.us> <1111715131.9085.174.camel@k2.cet.nau.edu> <3750.1111715318@sss.pgh.pa.us> <4243879B.10200@familyhealth.com.au> <20845.1111733900@sss.pgh.pa.us> <1111763448.11750.730.camel@localhost.localdomain> <23515.1111763837@sss.pgh.pa.us> <1111766478.11750.762.camel@localhost.localdomain> <20050325082101.G4358@megazone.bigpanda.com> <1111775050.11750.790.camel@localhost.localdomain> <28057.1111776442@sss.pgh.pa.us> <1111782529.11750.815.camel@localhost.localdomain> <20050325130124.U15470@megazone.bigpanda.com> Comments: In-reply-to Stephan Szabo message dated "Fri, 25 Mar 2005 13:10:51 -0800" Date: Fri, 25 Mar 2005 16:25:09 -0500 Message-ID: <12831.1111785909@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.007 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200503/564 X-Sequence-Number: 11269 Stephan Szabo writes: > On Fri, 25 Mar 2005, Simon Riggs wrote: >> Could it be that because PostgreSQL has a very highly developed sense of >> datatype comparison that we might be taking this to extremes? Would any >> other RDBMS consider two different datatypes to be comparable? > We do have a broader comparable than the spec. However, the set of comparisons that we can presently support *with indexes* is narrower than the spec, so rejecting nonindexable cases would be a problem. It's worth noting also that the test being discussed checks whether the PK index is usable for testing the RI constraint. In the problem that started this thread, the difficulty is lack of a usable index on the FK column, not the PK (because that's the table that has to be searched to do a delete in the PK table). We cannot enforce that there be a usable index on the FK column (since indexes on the FK table may not have been built yet when the constraint is declared), and shouldn't anyway because there are reasonable usage patterns where you don't need one. regards, tom lane