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 E4F99528CE for ; Mon, 13 Jun 2005 12:49:13 -0300 (ADT) 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 56487-01 for ; Mon, 13 Jun 2005 15:49:09 +0000 (GMT) Received: from wolff.to (wolff.to [66.93.197.194]) by svr1.postgresql.org (Postfix) with SMTP id 72F21528C1 for ; Mon, 13 Jun 2005 12:49:07 -0300 (ADT) Received: (qmail 9962 invoked by uid 500); 13 Jun 2005 15:48:34 -0000 Date: Mon, 13 Jun 2005 10:48:34 -0500 From: Bruno Wolff III To: John A Meinel Cc: Kevin Grittner , linux@alteeve.com, tgl@sss.pgh.pa.us, tobias@nordicbet.com, pgsql-performance@postgresql.org Subject: Re: Index ot being used Message-ID: <20050613154834.GA9203@wolff.to> Mail-Followup-To: Bruno Wolff III , John A Meinel , Kevin Grittner , linux@alteeve.com, tgl@sss.pgh.pa.us, tobias@nordicbet.com, pgsql-performance@postgresql.org References: <42AD9D8D.9060503@arbash-meinel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42AD9D8D.9060503@arbash-meinel.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.008 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/297 X-Sequence-Number: 12934 On Mon, Jun 13, 2005 at 09:51:57 -0500, John A Meinel wrote: > > I don't know if there are specific reasons why not, other than just not > being implemented yet. It might be tricky to get it correct (for > instance, how do you know which columns can be added, which ones will be > constant) Perhaps you could just potentially add the WHERE items if they > have an equality constraint with a constant. But I'm guessing there are > more cases than that where the optimization could be performed. I think there is already some intelligence about which expressions are constant in particular parts of a plan. I think you need to be able to do two things. One is to drop constant expressions from order by lists. The other is when looking for an index to produce a specific ordering, to ingore leading constant expressions when comparing to the order by expressions. > Also, the more options you give the planner, the longer it takes on > average to plan any single query. Yes, it is beneficial for this use > case, but does that balance out slowing down all the other queries by a > tiny bit. But there aren't that many possible indexes, so I don't expect this will slow things down much more than the current check for potentially useful indexes.