> >The index could then make sensible the reasonably common practice of
> >using a covered index - i.e. putting additional columns into the index
> >to satisfy the whole query just from the index.

> I am willing to take it on and I understand that the workload is mine.  
> As long as everyone gives me some suggestions, I'm good it being optional.

If nobody is working on it, you may find that the below TODO item might
accomplish most of what you're looking for as well as generally
improving performance. The count(*) on a where clause would result in
one index scan and one partial sequential heap scan. Not as fast for the
specific examples you've shown, but far better than today and covers
many other cases as well.

        Fetch heap pages matching index entries in sequential order 
        
        Rather than randomly accessing heap pages based on index
        entries, mark heap pages needing access in a bitmap and do the
        lookups in sequential order. Another method would be to sort
        heap ctids matching the index before accessing the heap rows.

In response to

• Re: Much Ado About COUNT(*) at 2005-01-12 21:58:14 from Jonah H. Harris

pgsql-announce by date

Next:	From: Jeff Davis	Date: 2005-01-13 02:45:09
	Subject: Re: Much Ado About COUNT(*)
Previous:	From: Jonah H. Harris	Date: 2005-01-12 21:58:14
	Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:	From: Mark Wong	Date: 2005-01-12 22:18:36
	Subject: sparse (static analyzer) report
Previous:	From: Jim Buttafuoco	Date: 2005-01-12 21:59:43
	Subject: Re: PANIC: right sibling's left-link doesn't match

pgsql-patches by date

Next:	From: Jeff Davis	Date: 2005-01-13 02:45:09
	Subject: Re: Much Ado About COUNT(*)
Previous:	From: Jonah H. Harris	Date: 2005-01-12 21:58:14
	Subject: Re: Much Ado About COUNT(*)