| From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: Index scan startup time |
| Date: | 2006-03-30 13:29:17 |
| Message-ID: | 20060330132915.GL6811@mathom.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Mar 30, 2006 at 02:51:47PM +0200, Steinar H. Gunderson wrote:
>On Thu, Mar 30, 2006 at 07:42:53AM -0500, Michael Stone wrote:
>> Yes. And the estimates are bad enough (orders of magnitude) that I can't
>> help but wonder whether pg could come up with a better plan with better
>> statistics:
>>
>>>>>> -> Index Scan using activity_pk on activity (cost=0.00..40717259.91
>>>>>> rows=6538650 width=8) (actual time=207356.050..207356.722 rows=100
>>>>>> loops=1) Filter: ((state = 10000) OR (state = 10001))
>
>Isn't the rows=100 here because of the LIMIT?
Yes. I was looking at the other side; I thought pg could estimate how
much work it would have to do to hit the limit, but double-checking it
looks like it can't.
Mike Stone
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-03-30 14:25:57 | Re: Index scan startup time |
| Previous Message | Steinar H. Gunderson | 2006-03-30 13:00:41 | Re: Index scan startup time |