Re: Speeding up Aggregates

On Thu, 9 Oct 2003, Dror Matalon wrote:

> On Thu, Oct 09, 2003 at 07:07:00PM -0400, Greg Stark wrote:
> > Dror Matalon <dror(at)zapatec(dot)com> writes:
> >
> > > Actually what finally sovled the problem is repeating the
> > > dtstamp > last_viewed
> > > in the sub select
> >
> > That will at least convince the optimizer to use an index range lookup. But it
> > still will have to scan every record that matches channel==$1, link==$2, and
> > dtstamp>$3.
> >
> > The trick of using limit 1 will be faster still as it only has to retrieve a
> > single record using the index. But you have to be sure to convince it to use
>
> How is doing order by limit 1 faster than doing max()? Seems like the
> optimizer will need to sort or scan the data set either way. That part
> didn't actually make a difference in my specific case.
>

max(field) = sequential scan looking for the hightest.

order by field desc limit 1 = index scan (if available), read first
record.
else (if no index) sequential scan for highest.

aggregates don't use indexes because its only appilicable for
max() and min() and can't be done for sum(), count(), etc writing an
alogorithim to use the index would be complex as you would need to tell
the optimized from the inside a function (you can write aggrate functions
your self if you wish) to do somthing slighly differently.

for my large table....
select max(field) from table; (5264.21 msec)
select field from table order by field limit 1; (54.88 msec)

Peter Childs