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
|
Список | 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 по дате отправления: