Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TOtYP-00089q-1d for pgsql-performance@postgresql.org; Thu, 18 Oct 2012 17:06:41 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TOtYK-00063g-3I for pgsql-performance@postgresql.org; Thu, 18 Oct 2012 17:06:40 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q9IH6Wag000604; Thu, 18 Oct 2012 13:06:32 -0400 (EDT) From: Tom Lane To: Peter Geoghegan cc: Thom Brown , pgsql-performance Subject: Re: Unused index influencing sequential scan plan In-reply-to: References: <102.1350578667@sss.pgh.pa.us> <293.1350579133@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Thu, 18 Oct 2012 18:00:43 +0100" Date: Thu, 18 Oct 2012 13:06:32 -0400 Message-ID: <603.1350579992@sss.pgh.pa.us> X-Pg-Spam-Score: -2.3 (--) X-Archive-Number: 201210/254 X-Sequence-Number: 48213 Peter Geoghegan writes: > Is there a case to be made for a index access method whose > pseudo-indexes costs essentially nothing to maintain, and simply > represent an ongoing obligation for ANALYZE to provide statistics for > an expression? If we were going to support it, I think we'd be better off exposing such a feature as DDL having nothing to do with indexes. Not sure it's worth the trouble though. The ANALYZE wart to compute stats for index expressions has been there a long time, and there's been essentially zero field demand for another way to do it. What people really seem to care about is more intelligence about making use of expression indexes to avoid recalculation of the expression --- something you'd not get from a stats-only feature. regards, tom lane