Re: Select max(foo) and select count(*) optimization

On Tuesday 06 January 2004 07:16, Christopher Browne wrote:
> Martha Stewart called it a Good Thing when paul(at)tuckfield(dot)com (Paul
Tuckfield) wrote:
> > Not that I'm offering to do the porgramming mind you, :) but . .
> >
> > In the case of select count(*), one optimization is to do a scan of the
> > primary key, not the table itself, if the table has a primary key. In a
> > certain commercial, lesser database, this is called an "index fast full
> > scan". It would be important to scan the index in physical order
> > (sequential physical IO) and not in key order (random physical IO)
>
> The problem is that this "optimization" does not actually work. The
> index does not contain transaction visibility information, so you have
> to go to the pages of tuples in order to determine if any given tuple
> is visible.

It was rejected as an idea to add transaction visibility information to
indexes. The time I proposed, my idea was to vacuum tuples on page level
while postgresql pushes buffers out of shared cache. If indexes had
visibility information, they could be cleaned out of order than heap tuples.

This wouldn't have eliminated vacuum entirely but at least frequently hit data
would be clean.

But it was rejected because of associated overhead.

Just thought worh a mention..

Shridhar