| From: | Andreas Kretschmer <akretschmer(at)spamfence(dot)net> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: seq scan over 3.3 million rows instead of single key index access |
| Date: | 2008-11-23 08:13:39 |
| Message-ID: | 20081123081339.GB7443@tux |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Andrus <kobruleht2(at)hot(dot)ee> schrieb:
> There are indexes on rid(dokumnr) and dok(dokumnr) and dokumnr is int.
> Instead of using single key index, 8.1.4 scans over whole rid table.
> Sometimes idtelluued can contain more than single row so replacing join
> with equality is not possible.
>
> How to fix ?
>
> Andrus.
>
> CREATE TEMP TABLE idtellUued(dokumnr INT) ON COMMIT DROP;
> INSERT INTO idtellUued VALUES(1249228);
> explain analyze select 1
> from dok JOIN rid USING(dokumnr)
> JOIN idtellUued USING(dokumnr)
Try to analyse the idtellUued-table after the insert. The planner has no
knowledge that this table contains only one or e few rows, the planner
assume 1000 (iirc) in this table.
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrus | 2008-11-23 11:43:08 | Re: seq scan over 3.3 million rows instead of single keyindex access |
| Previous Message | Andreas Kretschmer | 2008-11-23 08:10:24 | Re: seq scan over 3.3 million rows instead of single key index access |