Skip site navigation (1) Skip section navigation (2)

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

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Select max(foo) and select count(*) optimization
Date: 2004-01-06 06:31:53
Message-ID: 200401061201.53978.shridhar_daithankar@persistent.co.in (view raw or flat)
Thread:
Lists: pgsql-performance
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



In response to

pgsql-performance by date

Next:From: Shridhar DaithankarDate: 2004-01-06 06:42:21
Subject: Re: Select max(foo) and select count(*) optimization
Previous:From: Bruce MomjianDate: 2004-01-06 05:25:32
Subject: Re: optimizing Postgres queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group