Re: seq scan over 3.3 million rows instead of single key index access
| От | Andreas Kretschmer |
|---|---|
| Тема | Re: seq scan over 3.3 million rows instead of single key index access |
| Дата | |
| Msg-id | 20081123081339.GB7443@tux обсуждение исходный текст |
| Ответ на | seq scan over 3.3 million rows instead of single key index access ("Andrus" <kobruleht2@hot.ee>) |
| Список | pgsql-performance |
Andrus <kobruleht2@hot.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°
В списке pgsql-performance по дате отправления: