Re: Speeding up Aggregates

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.

> the index and the way to do that is to list exactly the same columns in the
> ORDER BY as are in the index definition.
>
> Even if some of the leading columns are redundant because they'll be constant
> for all of the records retrieved. The optimizer doesn't know to ignore those.

The main problem in my case was that the optimizer was doing the max()
on all 700 rows, rather than the filtered rows. It's not until I put the
"dtstamp> last_viewed" in the sub select as well as in the main query
that it realized that it can first filter the 696 rows out and then to
the max() on the 4 rows that satisfied this constraint.

That was the big saving.

Hope this all makes sense,

Dror
>
> > > (This is the thing i pointed out previously in
> > > <87el6ckrlu(dot)fsf(at)stark(dot)dyndns(dot)tv> on Feb 13th 2003 on pgsql-general)
>
> --
> greg
>

--
Dror Matalon
Zapatec Inc
1700 MLK Way
Berkeley, CA 94709
http://www.zapatec.com