Greg Stark wrote:
> On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian <br...@momjian.us> wrote:
> > Isn't speeding up COUNT(*) a sufficient case because it will not have to
> > touch the heap in many cases?
> 
> 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
> to pages where the heap reference can be optimized away. The penalty
> for guessing wrong if we use an index-only scan and it turns out to
> have many pages that aren't all-visible would be pretty high.

Yes, that is the tricky optimizer/analyze part.

-- 
  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to