Postgres定期“忘记”其指数并开始放缓。 我做分析,并“回忆”它的指数。
一切都会好的,但上次这发生在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)
Hello depesz,这里是分析输出。 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)
答案 0 :(得分:1)
答案 1 :(得分:0)
嗯听起来像自动真空可能已经疲惫不堪,你可能想查看相关的日志并向那个方向挖掘一下。