From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
cc: sthomas@optionshouse.com,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Setting Statistics on Functional Indexes
In-reply-to: 
 <CAGTBQpbDZw3CVE9mgc_tS3a_ovjjg5YKnHQ=XrM89JNbaA9PvQ@mail.gmail.com>
References: <50881D73.100@optionshouse.com> <6668.1351105908@sss.pgh.pa.us>
	<508841FF.9040303@optionshouse.com>
	<5088478C.6000905@optionshouse.com> <1511.1351280130@sss.pgh.pa.us>
	<508AEB1A.2040001@optionshouse.com> <3040.1351285698@sss.pgh.pa.us>
	<CAGTBQpbDZw3CVE9mgc_tS3a_ovjjg5YKnHQ=XrM89JNbaA9PvQ@mail.gmail.com>
Comments: In-reply-to Claudio Freire <klaussfreire@gmail.com>
	message dated "Fri, 26 Oct 2012 18:19:05 -0300"
Date: Fri, 26 Oct 2012 18:01:38 -0400
Message-ID: <3989.1351288898@sss.pgh.pa.us>

Claudio Freire <klaussfreire@gmail.com> writes:
> Because once you've accessed that last index page, it would be rather
> trivial finding out how many duplicate tids are in that page and, with
> a small CPU cost (no disk access if you don't query other index pages)
> you could verify the assumption of near-uniqueness.

I thought about that too, but I'm not sure how promising the idea is.
In the first place, it's not clear when to stop counting duplicates, and
in the second, I'm not sure we could get away with not visiting the heap
to check for tuple liveness.  There might be a lot of apparent
duplicates in the index that just represent unreaped old versions of a
frequently-updated endpoint tuple.  (The existing code is capable of
returning a "wrong" answer if the endpoint tuple is dead, but I don't
think it matters much in most cases.  I'm less sure such an argument
could be made for dup-counting.)

			regards, tom lane