Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 25C5764FD20 for ; Thu, 4 Sep 2008 15:45:56 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 55393-10 for ; Thu, 4 Sep 2008 15:45:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from dnsmail.rentrak.com (mtx2.rentrak.com [208.26.192.5]) by postgresql.org (Postfix) with ESMTP id 5BF0864FD33 for ; Thu, 4 Sep 2008 15:45:48 -0300 (ADT) Received: from rtk_mail_2.rentrak.com (gwsmtp.rentrak.com [208.26.192.7]) by dnsmail.rentrak.com (Postfix) with ESMTP id DBE7C299E8 for ; Thu, 4 Sep 2008 11:45:39 -0700 (PDT) Received: from Oregon1-MTA by rtk_mail_2.rentrak.com with Novell_GroupWise; Thu, 04 Sep 2008 11:45:39 -0700 Message-Id: <48BFCA55.D078.0028.0@rentrak.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Thu, 04 Sep 2008 11:45:37 -0700 From: "Matt Smiley" To: "Tom Lane" Cc: , Subject: Re: limit clause breaks query planner? References: <48BD33B2.D078.0028.0@rentrak.com><48BD33B2.D078.0028.0@rentrak.com> <5925.1220389248@sss.pgh.pa.us> <48BF195E.D078.0028.0@rentrak.com><48BF195E.D078.0028.0@rentrak.com> <23341.1220542340@sss.pgh.pa.us> In-Reply-To: <23341.1220542340@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/58 X-Sequence-Number: 31371 "Tom Lane" writes: > I'm not sure offhand whether the existing correlation stats would be of = use for > it, or whether we'd have to get ANALYZE to gather additional data. Please forgive the tangent, but would it be practical to add support for = gathering statistics on an arbitrary expression associated with a table, = rather than just on materialized columns? For example: analyze my_tab for expression 'my_func(my_tab.col)' ; It seems like any time you'd consider using a functional index, this = feature would let the planner calculate decent selectivity estimates for = the expression's otherwise opaque data distribution. The expression might = be treated as a virtual column on the table; not sure if that helps or = hurts. Should I post this question on pgsql-hackers?