| From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: Index scan startup time |
| Date: | 2006-03-30 12:42:53 |
| Message-ID: | 20060330124251.GK6811@mathom.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Mar 30, 2006 at 02:31:34PM +0200, Steinar H. Gunderson wrote:
>Well, it's logical enough; it scans along activity_id until it finds one with
>state=10000 or state=10001. You obviously have a _lot_ of records with low
>activity_id and state none of these two, so Postgres needs to scan all those
>records before it founds 100 it can output. This is the “startup cost” you're
>seeing.
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))
Mike Stone
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steinar H. Gunderson | 2006-03-30 12:51:47 | Re: Index scan startup time |
| Previous Message | Markus Schaber | 2006-03-30 12:35:53 | Re: Index scan startup time |