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

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.

> I'm guessing the payoff as well as real-world-utility of a max(xxx)
> optimization are much higher than a count(*) optimization tho

That's probably so.

In many cases, approximations, such as page counts, may be good
enough, and pray consider, that ("an approximation") is probably all
you were getting from the database systems that had an "optimization"
to store the count in a counter.
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"No, you misunderstand. Microsoft asked some hackers how they could
make their system secure - the hackers replied "Turn it off.". So they
did." -- Anthony Ord