Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: the big picture for index-only scans
Date
Msg-id 201105110300.p4B30pk04429@momjian.us
Whole thread Raw
In response to Re: the big picture for index-only scans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Greg Stark wrote:
> >> Putting aside the politics questions, count(*) is an interesting case
> >> -- it exposes some of the unanswered questions about index-only scans.
> >> 
> >> The reason "select count(*)" might win would be because we could pick
> >> any index and do an index scan, relying on the visibility map to
> >> optimize away the heap reads. This is only going to be a win if a
> >> large fraction of the heap reads get optimized away.
> >> 
> >> It's going to be pretty tricky to determine in the optimizer a) which
> >> index will be cheapest and b) what fraction of index tuples will point
> 
> > I assume the smallest non-partial index would be the cheapest index.
> 
> That will be true only if you intentionally ignore the points Greg
> raised.  If the table isn't entirely ALL_VISIBLE, then the choice of
> index will determine the ordering of the actual table probes that occur.
> There could be more or fewer page reads, in a more or less optimal
> order, depending on the index used.

OK, would the clustering analyze stats (pg_stats.correlation) tell us
that?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: VARIANT / ANYTYPE datatype
Next
From: Brar Piening
Date:
Subject: Re: Windows build issues