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: 20081123081024.GA7443@tux
(см: обсуждение, исходный текст)
Ответ на: seq scan over 3.3 million rows instead of single key index access  ("Andrus")
Ответы: Re: seq scan over 3.3 million rows instead of single keyindex access  ("Andrus")
Список: pgsql-performance

Скрыть дерево обсуждения

seq scan over 3.3 million rows instead of single key index access  ("Andrus", )
 Re: seq scan over 3.3 million rows instead of single key index access  (Gregory Stark, )
  Re: seq scan over 3.3 million rows instead of single key index access  (Tom Lane, )
  Re: seq scan over 3.3 million rows instead of single key index access  ("Andrus", )
   Re: seq scan over 3.3 million rows instead of single key index access  ("A. Kretschmer", )
 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 keyindex access  ("Andrus", )
 Re: seq scan over 3.3 million rows instead of single key index access  (Andreas Kretschmer, )

Andrus <> 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)
>
> "Hash Join  (cost=7483.22..222259.77 rows=5706 width=0) (actual
> time=14905.981..27065.903 rows=8 loops=1)"
> "  Hash Cond: ("outer".dokumnr = "inner".dokumnr)"
> "  ->  Seq Scan on rid  (cost=0.00..198240.33 rows=3295833 width=4)
> (actual time=0.036..15021.641 rows=3280576 loops=1)"

How many rows contains rid? The estimation are okay, rows=3295833 and
actual rows=3280576 are nearly identical. An index-scan makes only sense
if rid contains considerable more than 3000000 rows.


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 по дате сообщения:

От: "Andrus"
Дата:
Сообщение: Re: seq scan over 3.3 million rows instead of single keyindex access
От: "Andrus"
Дата:
Сообщение: Re: Hash join on int takes 8..114 seconds