Postgres 테이블 선택 쿼리가 너무 느림

Question

gps 추적 응용 프로그램이 있습니다. 들어오는 gps 데이터가 자주 저장되는 gps_vehicle_data라는 테이블이 있습니다. 원시 데이터가 포함되어 있으므로이 테이블을 자주 간격으로 쿼리하여 처리합니다. 최근에 테이블에서 select 문을 실행하는 데 많은 시간이 걸렸습니다. 다음은 EXPLAIN의 결과입니다. 또한 VACUUM &을 아래에 붙여 넣으려고했습니다. 그 이유는 무엇일까요?

EXPLAIN (ANALYZE, BUFFERS) select * from gps_vehicle_data; 

                  QUERY PLAN                
--------------------------------------------------------------------------------------------------------------------------------- 
Seq Scan on gps_vehicle_data (cost=0.00..130818.81 rows=1400881 width=1483) (actual time=209.129..62488.822 rows=9635 loops=1) 
    Buffers: shared hit=13132 read=103678 dirtied=67 written=25 
Planning time: 0.050 ms 
Execution time: 62500.850 ms 

진공 출력.

VACUUM (VERBOSE,ANALYSE) gps_vehicle_data; 
INFO: vacuuming "public.gps_vehicle_data" 
INFO: index "gps_vehicle_data_pkey" now contains 1398939 row versions in 10509 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.07s/0.09u sec elapsed 9.38 sec. 
INFO: index "gps_vehicle_data_status_idx" now contains 1398939 row versions in 4311 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.03s/0.04u sec elapsed 4.50 sec. 
INFO: index "gps_vehicle_data_url_data_idx" now contains 1399004 row versions in 98928 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.76s/0.88u sec elapsed 82.74 sec. 
INFO: index "gps_vehicle_data_createdon_idx" now contains 1399007 row versions in 3946 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.00s/0.02u sec elapsed 1.92 sec. 
INFO: "gps_vehicle_data": found 0 removable, 1402484 nonremovable row versions in 116884 out of 116884 pages 
DETAIL: 1401490 dead row versions cannot be removed yet. 
There were 143431 unused item pointers. 
Skipped 0 pages due to buffer pins. 
0 pages are entirely empty. 
CPU 1.70s/2.38u sec elapsed 200.61 sec. 
INFO: vacuuming "pg_toast.pg_toast_17296" 
INFO: index "pg_toast_17296_index" now contains 0 row versions in 1 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.00s/0.00u sec elapsed 0.01 sec. 
INFO: "pg_toast_17296": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages 
DETAIL: 0 dead row versions cannot be removed yet. 
There were 0 unused item pointers. 
Skipped 0 pages due to buffer pins. 
0 pages are entirely empty. 
CPU 0.00s/0.00u sec elapsed 0.01 sec. 
INFO: analyzing "public.gps_vehicle_data" 
INFO: "gps_vehicle_data": scanned 30000 of 116884 pages, containing 335 live rows and 359656 dead rows; 335 rows in sample, 1042851 estimated total rows 
VACUUM 

Answer 1

당신은 당신의 테이블이 (가 테이블 팽창을 앓고) 거의 무 (無)로 구성되어 있음을 의미, 일부 10,000 행을 얻을 이상 100000 블록을 읽어 보시기 바랍니다.

테이블에는 더 많은 데이터가 포함되어 있어야하며 그 중 대부분은 삭제 된 이후로 부풀어졌습니다.

@a_horse_with_no_name에서 언급했듯이 일부 오래된 트랜잭션이이를 차단하고 있기 때문에 일부 행을 회수 할 수 없지만 VACUUM은 불필요한 행을 제거하지만 부풀림을 없애기 위해 테이블을 재구성하지는 않습니다.

이 경우 정확한 해결책은 VACUUM (FULL, ANALYZE) gps_vehicle_data입니다 (테이블 통계가 꺼져있는 것 같기 때문에 ANALYZE은 좋은 조치입니다). 그러면 테이블이 재구성됩니다. 그러나 VACUUM (FULL)이 실행되는 동안 테이블에 대한 모든 액세스가 차단된다는 경고를받습니다.