Re: the big picture for index-only scans

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Greg Stark" <gsstark(at)mit(dot)edu>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: the big picture for index-only scans
Date: 2011-05-11 14:38:15
Message-ID: 4DCA5907020000250003D559@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> wrote:

>> The very fact that Kevin and yourself bring up different reasons
>> for why we need this feature makes me nervous.
>
> Yes, no question. For count(*), you don't care about the indexed
> values, only the count, while for Kevin's case you are reading
> values from the index.

[sigh] I'm reluctant to draw out this digression further, but there
is a possibly-useful point to be made here: these are not two
different things. A covering index can be considered whenever the
set of columns referenced in the query is contained inside the set
of columns in the index. The fact that the set of columns needed by
count(*) is the empty set merely means that it is covered by any
index, since the empty set is contained in every set.

Now, this special case may make for an easy initial target in
implementation, or allow early benchmarking. If so, all the better
to go there first. I'm not sure why anyone would stop there,
though; if it pays off for that simple case it is likely to pay off
for the more general case, too.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2011-05-11 14:40:49 Fix for bug in ldapServiceLookup in libpq
Previous Message Bruce Momjian 2011-05-11 14:22:49 Re: the big picture for index-only scans