From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Dror Matalon <dror(at)zapatec(dot)com> |
Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Speeding up Aggregates |
Date: | 2003-10-09 23:07:00 |
Message-ID: | 87ekxm9fjf.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
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.
> > (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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2003-10-09 23:32:22 | Re: backup/restore - another area. |
Previous Message | Kenneth Marshall | 2003-10-09 20:31:24 | Re: Sun performance - Major discovery! |