| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Bob Duffey" <bobduffey68(at)gmail(dot)com> |
| Cc: | "Steve Atkins" <steve(at)blighty(dot)com>, "pgsql-general General" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: query planner weirdness? |
| Date: | 2008-06-28 15:08:29 |
| Message-ID: | 28468.1214665709@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Bob Duffey" <bobduffey68(at)gmail(dot)com> writes:
> 2008/6/28 Steve Atkins <steve(at)blighty(dot)com>:
>> If you're iterating through the records with a cursor, the plan may
>> be different, IIRC - weighted to provide first row quickly, as opposed
>> to the query that was run that's weighted to provide last row quickly.
>>
> I agree, and I was hoping that would be the case, but as it happens it
> wasn't.
The planner does in fact pay more attention to first-row cost than total
cost when given a DECLARE CURSOR instead of a regular SELECT.
Apparently that wasn't enough to make the indexscan be preferred,
though, which is a bit curious. You might want to look at
effective_cache_size as well as random_page_cost.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Atkins | 2008-06-28 16:39:14 | Re: query planner weirdness? |
| Previous Message | hubert depesz lubaczewski | 2008-06-28 09:35:24 | Re: freebsd + postgresql 8.3.3 = 100% of cpu usage on stats collector? |