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 3FA003A467C for ; Mon, 1 Nov 2004 20:23:20 +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 55942-07 for ; Mon, 1 Nov 2004 20:23:10 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 8BB8A3A4674 for ; Mon, 1 Nov 2004 20:23:10 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id iA1KN9J7057887 for ; Mon, 1 Nov 2004 20:23:09 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id iA1JtuPn049398 for pgsql-sql@postgresql.org; Mon, 1 Nov 2004 19:55:56 GMT From: Mischa Sandberg Reply-To: ischamay.andbergsay@activestateway.com User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 X-Newsgroups: comp.databases.postgresql.sql Subject: Re: Join Table References: <41866598.5040909@numerixtechnology.de> <20041101170324.GA18943@winnie.fuhr.org> <41867C72.4060001@numerixtechnology.de> In-Reply-To: <41867C72.4060001@numerixtechnology.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 41 Message-ID: Date: Mon, 01 Nov 2004 19:55:57 GMT To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.1 tagged_above=0.0 required=5.0 tests=NO_DNS_FOR_FROM X-Spam-Level: * X-Archive-Number: 200411/56 X-Sequence-Number: 19375 T E Schmitz wrote: >> On Mon, Nov 01, 2004 at 04:34:32PM +0000, T E Schmitz wrote: >> >>> Question: is it necessary/advisable to create an index for the >>> ITEM_FK column? Or is this redundantbecause this column is already >>> one of the PK columns? >> >> However, read the "Multicolumn Indexes" section in the "Indexes" >> chapter to be sure you understand when the index will be used and >> when it won't be: >> >> http://www.postgresql.org/docs/7.4/static/indexes-multicolumn.html > > I see. If using a multi-column PK, the order matters. > So, if I want to access the table both via the 1st and 2nd PK column, I > would have to define an index for the 2nd column to avoid a full table > scan. > > Let's ask the question the other way round: I remember seeing a > discussion (re Oracle) whether to use a multi-column PK or a unique > constraint in such a situation - I got the impression it is one of these > "religious" discussions ;-). > What are the pros and cons? Oracle uses a tactic called 'index skip scan' that tries to make use of an index when the first column is not restricted by the query. http://www.oracle-base.com/articles/9i/IndexSkipScanning.php The idea is that scanning the data in the index is fast, and the results sets of rowids can be sorted and batched for (relatively) efficient retrieval from the heap. I've read one review that indicates there were pitfalls with using it in 9i: http://www.praetoriate.com/oracle_tips_skip_scan.htm Having used such schemes for querying (blush) ISAM files I'd say that this isn't surprising.