주기적으로 Postgres는 인덱스에 대해 "잊어 버리고"속도가 느려집니다. 나는 분석을하고 그것의 색인을 되찾는다.PostgreSQL은 인덱스에 대해 잊어 버림

모든 것이 괜찮을 것이지만 지난 번이 일이 2 시간 만 지나면 나는 분석을했습니다. 삭제가 없으며, 삽입 속도가 매우 느립니다. 시간당 약 10000입니다. 이것은 PostgreSQL 자체의 버그일까요? 버전 8.3.7

trio=# explain Select p.id, p.status 
trio-# From m_a a 
trio-# Join m_b p On a.m_id = p.id 
trio-# Where a.user_id = ? And a.tx = ? 
trio-# Order By a.id Desc 
trio-# Limit 1; 
QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=0.00..3335.25 rows=1 width=18) 
    -> Nested Loop (cost=0.00..673719.63 rows=202 width=18) 
    -> Index Scan Backward using m_a_pkey on m_a a (cost=0.00..671058.45 rows=202 width=8) 
     Filter: ((user_id = ?) AND (tx = ?::numeric)) 
    -> Index Scan using m_b_pkey on m_b p (cost=0.00..13.16 rows=1 width=14) 
     Index Cond: (p.id = a.m_id) 
(6 rows) 

trio=# analyze m_a; 
ANALYZE 
trio=# explain Select p.id, p.status 
trio-# From m_a a 
trio-# Join m_b p On a.m_id = p.id 
trio-# Where a.user_id = ? And a.tx = ? 
trio-# Order By a.id Desc 
trio-# Limit 1; 
QUERY PLAN 
-------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=23.18..23.18 rows=1 width=18) 
    -> Sort (cost=23.18..23.18 rows=1 width=18) 
    Sort Key: a.id 
    -> Nested Loop (cost=0.00..23.17 rows=1 width=18) 
     -> Index Scan using m_a_idx on m_a a (cost=0.00..9.99 rows=1 width=8) 
     Index Cond: ((user_id = ?) AND (tx = ?::numeric)) 
     -> Index Scan using m_b_pkey on m_b p (cost=0.00..13.16 rows=1 width=14) 
     Index Cond: (p.id = a.m_id) 
(8 rows)

===========

안녕하세요 depesz, 여기에 출력을 analize입니다. Avtovacuum이 켜져 있습니다.

#default_statistics_target = 10  # range 1-1000 




#------------------------------------------------------------------------------ 
# AUTOVACUUM PARAMETERS 
#------------------------------------------------------------------------------ 

autovacuum = on    # Enable autovacuum subprocess? 'on' 
        # requires track_counts to also be on. 
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and 
        # their durations, > 0 logs only 
        # actions running at least that time. 
#autovacuum_max_workers = 3  # max number of autovacuum subprocesses 
#autovacuum_naptime = 1min  # time between autovacuum runs 
#autovacuum_vacuum_threshold = 50 # min number of row updates before 
        # vacuum 
#autovacuum_analyze_threshold = 50 # min number of row updates before 
        # analyze 
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum 
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze 
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum 
        # (change requires restart) 
#autovacuum_vacuum_cost_delay = 20 # default vacuum cost delay for 
        # autovacuum, -1 means use 
        # vacuum_cost_delay 
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for 
        # autovacuum, -1 means use 
        # vacuum_cost_limit

==========

 QUERY PLAN                    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Limit (cost=22.07..22.07 rows=1 width=18) (actual time=0.308..0.309 rows=1 loops=1) 
    -> Sort (cost=22.07..22.07 rows=1 width=18) (actual time=0.306..0.306 rows=1 loops=1) 
     Sort Key: a.id 
     Sort Method: quicksort Memory: 25kB 
     -> Nested Loop (cost=0.00..22.06 rows=1 width=18) (actual time=0.277..0.280 rows=1 loops=1) 
       -> Index Scan using m_a_uidx on m_a a (cost=0.00..8.76 rows=1 width=8) (actual time=0.162..0.162 rows=1 loops=1) 
        Index Cond: ((user_id = ?) AND (tx = ?::numeric)) 
       -> Index Scan using m_b_pkey on m_b p (cost=0.00..13.29 rows=1 width=14) (actual time=0.109..0.111 rows=1 loops=1) 
        Index Cond: (p.id = a.m_id) 
Total runtime: 0.397 ms 
(10 rows)

출처

2009-09-08 Anonymous