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

From Tom Lane
Subject Re: the big picture for index-only scans
Date
Msg-id 17411.1305080982@sss.pgh.pa.us
Whole thread Raw
In response to Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
Responses Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
Re: the big picture for index-only scans  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: PGC_S_DEFAULT is inadequate
Next
From: Joseph Adams
Date:
Subject: Re: VARIANT / ANYTYPE datatype