Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 5E7B59FB415 for ; Mon, 23 Oct 2006 12:17:38 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 93053-03 for ; Mon, 23 Oct 2006 12:17:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 1B1009FB319 for ; Mon, 23 Oct 2006 12:17:14 -0300 (ADT) Received: from kingfisher.intern.logix-tt.com (84-72-188-217.dclient.hispeed.ch [84.72.188.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id A55D0656B6 for ; Mon, 23 Oct 2006 17:19:43 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 4EB0118532B06 for ; Mon, 23 Oct 2006 17:17:07 +0200 (CEST) Message-ID: <453CDCF2.6090208@logix-tt.com> Date: Mon, 23 Oct 2006 17:17:06 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: PostgreSQL Performance List Subject: Re: Index on two columns not used References: <45360E25.9010403@freesurf.fr> <45361295.9050504@enterprisedb.com> <4539F4E1.7000003@chemaxon.hu> <453CC2DD.4070608@logix-tt.com> <20061023135011.GG7961@alvh.no-ip.org> In-Reply-To: <20061023135011.GG7961@alvh.no-ip.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.132 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, SPF_HELO_SOFTFAIL, SPF_SOFTFAIL X-Spam-Level: ** X-Archive-Number: 200610/477 X-Sequence-Number: 21606 Hi, Alvaro, Alvaro Herrera wrote: >> Additionally, in most UPDATE cases, the new row version will fit into >> the same page as the old version. In this case, the index does not have >> to be changed, which is an additional speed improvement. > Actually, when the UPDATE puts a new row version in the same heap page, > the index must be updated anyway. AFAICS only, when the index covers (directly or via function) a column that's actually changed. Changing columns the index does not depend on should not need any write access to that index. Correct me if I'm wrong. Thanks, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org