X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 214AA32A828 for ; Sat, 9 Oct 2004 19:08:57 +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 21064-01 for ; Sat, 9 Oct 2004 18:08:54 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by svr1.postgresql.org (Postfix) with ESMTP id 2259432A827 for ; Sat, 9 Oct 2004 19:08:54 +0100 (BST) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 6326870D1D5 for ; Sat, 9 Oct 2004 15:08:53 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 17110-10 for ; Sat, 9 Oct 2004 18:08:51 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by hub.org (Postfix) with ESMTP id A3F5670CC94 for ; Sat, 9 Oct 2004 15:08:51 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id DA4633EDA2; Sat, 9 Oct 2004 15:08:51 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id D68C73E5CF for ; Sat, 9 Oct 2004 15:08:51 -0300 (ADT) Date: Sat, 9 Oct 2004 15:08:51 -0300 (ADT) From: "Marc G. Fournier" To: pgsql-sql@postgresql.org Subject: How do FKs work? Message-ID: <20041009145332.D54093@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200410/62 X-Sequence-Number: 19165 Got a problem here, and this is a new area for me ... analyzing FKs and improving their performance :) Have a table with two FKs on it ... 2 different fields in the table point to the same field in another table ... When I do an 'EXPLAIN ANALYZE DELETE FROM table WHERE field = #;', it never comes back ... or, at lesat, takes a *very* long time ... If I do a count(1) for that #, there are 1639 rows ... Now, 'ON DELETE' is set to 'NO ACTION', so my *guess* is that all it does is a 'SELECT FROM table WHERE field = value' on the referenced table, to make sure it exists ... Is this correct? So, its effectively having to do 3278 "SELECTS" against the REFERENCED table? (two fields have contraints on them, 1639 rows to be deleted) ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664