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 368D0537EC for ; Fri, 25 Mar 2005 15:12:09 +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 98647-01 for ; Fri, 25 Mar 2005 15:12:02 +0000 (GMT) Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by svr1.postgresql.org (Postfix) with ESMTP id 979835369F for ; Fri, 25 Mar 2005 15:12:01 +0000 (GMT) Received: from modem-1391.llama.dialup.pol.co.uk ([217.135.181.111] helo=192.168.0.102) by cmailg1.svr.pol.co.uk with esmtp (Exim 4.14) id 1DEqTf-0006Sg-U7; Fri, 25 Mar 2005 15:12:00 +0000 Subject: Re: Delete query takes exorbitant amount of time From: Simon Riggs To: Tom Lane , Karim Nassar Cc: Christopher Kings-Lynne , pgsql-performance@postgresql.org In-Reply-To: <20845.1111733900@sss.pgh.pa.us> 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> Content-Type: text/plain Organization: 2nd Quadrant Date: Fri, 25 Mar 2005 15:10:48 +0000 Message-Id: <1111763448.11750.730.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/542 X-Sequence-Number: 11247 On Fri, 2005-03-25 at 01:58 -0500, Tom Lane wrote: > Christopher Kings-Lynne writes: > >> In that case there's a datatype mismatch between the referencing and > >> referenced columns, which prevents the index from being used for the > >> FK check. > > > Is creating such a foreign key a WARNING yet? > > I believe so as of 8.0. It's a bit tricky since 8.0 does allow some > cross-type cases to be indexed, but IIRC we have a test that understands > about that... src/backend/commands/tablecmds.c, line 3966 in CVSTIP /* * Check that the found operator is compatible with the PK index, * and generate a warning if not, since otherwise costly seqscans * will be incurred to check FK validity. */ if (!op_in_opclass(oprid(o), opclasses[i])) ereport(WARNING, (errmsg("foreign key constraint \"%s\" " "will require costly sequential scans", fkconstraint->constr_name), errdetail("Key columns \"%s\" and \"%s\" " "are of different types: %s and %s.", strVal(list_nth(fkconstraint->fk_attrs, i)), strVal(list_nth(fkconstraint->pk_attrs, i)), format_type_be(fktypoid[i]), format_type_be(pktypoid[i])))); So, yes to the WARNING. Not sure about the cross-type cases... Karim: Did this happen? If not, can you drop and re-create and confirm that you get the WARNING? If not, we have problems. I vote to make this an ERROR in 8.1 - I see little benefit in allowing this situation to continue. If users do create a FK like this, it just becomes another performance problem on list... Best Regards, Simon Riggs