Re: Indexes not always used after inserts/updates/vacuum

Поиск
Список
Период
Сортировка
От Reinhard Max
Тема Re: Indexes not always used after inserts/updates/vacuum
Дата
Msg-id Pine.LNX.4.44.0202281243330.6623-100000@Wotan.suse.de
обсуждение исходный текст
Ответ на Re: Indexes not always used after inserts/updates/vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Indexes not always used after inserts/updates/vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Wed, 27 Feb 2002 at 22:57, Tom Lane wrote:

> Also, to put the rubber to the road: if you force an indexscan by
> doing "set enable_seqscan = off", does it get faster or slower?
> (EXPLAIN ANALYZE would be useful here.)

I've just found a case where forcing indexscans results in much higher
speed. On the the 350000 rows table mentioned in my other post after a
"VACUUM FULL ANALYZE":

max=# set enable_seqscan to false;
max=# EXPLAIN analyze
    SELECT count(foo.id) FROM foo, bar
    WHERE foo.id = bar.ref2foo;
Aggregate    (cost=27513.65..27513.65 rows=1 width=8)
        (actual time=652.38..652.38 rows=1 loops=1)
  ->  Merge Join
        (cost=0.00..27417.57 rows=38431 width=8)
        (actual time=0.06..603.02 rows=38431 loops=1)
        ->  Index Scan using foo_pkey on foo
        (cost=0.00..25153.18 rows=352072 width=4)
        (actual time=0.03..157.57 rows=38432 loops=1)
        ->  Index Scan using idx_bar_ref2foo on bar
        (cost=0.00..807.74 rows=38431 width=4)
        (actual time=0.02..170.25 rows=38431 loops=1)
Total runtime: 652.58 msec
               ^^^^^^^^^^^
max=# set enable_seqscan to true;
max=# EXPLAIN analyze
    SELECT count(foo.id) FROM foo, bar
    WHERE foo.id = bar.ref2foo;

Aggregate
        (cost=18560.65..18560.65 rows=1 width=8)
        (actual time=4951.57..4951.57 rows=1 loops=1)
  ->  Hash Join
        (cost=911.39..18464.58 rows=38431 width=8)
        (actual time=653.26..4905.37 rows=38431 loops=1)
        ->  Seq Scan on foo
        (cost=0.00..9251.72 rows=352072 width=4)
        (actual time=0.02..769.60 rows=352072 loops=1)
        ->  Hash
        (cost=683.31..683.31 rows=38431 width=4)
        (actual time=140.60..140.60 rows=0 loops=1)
              ->  Seq Scan on bar
        (cost=0.00..683.31 rows=38431 width=4)
        (actual time=0.02..78.57 rows=38431 loops=1)
Total runtime: 4951.70 msec
               ^^^^^^^^^^^^

I've reproduced that several times. Even on a newly started postmaster
the query takes less than 2.5 seconds with seqscans swited off.

cu
    Reinhard

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Michael G. Martin"
Дата:
Сообщение: Re: Indexes not always used after inserts/updates/vacuum analyze
Следующее
От: "Michael G. Martin"
Дата:
Сообщение: Re: Indexes not always used after inserts/updates/vacuum analyze