postgresql: какой индекс не используется в поисковом запросе "select" - PullRequest
Новая
       3

postgresql: какой индекс не используется в поисковом запросе "select"

0 голосов
/ 31 мая 2018

У меня есть два сервера БД на разных компьютерах, которые имеют один и тот же файл конфигурации.Я называю их A & B, 600 + M записей в A (онлайн) и 600M записей в B (тест).

Проблема:

Я создаю один и тот же индекс для A и B,все они находятся в таблице tasks, столбец time.Когда я делаю один и тот же поиск выбора (explain analyze select * from tasks order by time desc limit 1) в A и B, поиск в A никогда не выполняет пользовательское индексное сканирование, но использует B, даже я запретил enable_seqscan для A.

Так же, как индекс для A никогда не существует!Но \d tasks показывает, что в нем существует временной индекс.

ИНФОРМАЦИЯ О ТАБЛИЦЕ: 

                                Table "public.tasks"
     Column     |     Type      |                     Modifiers                      
----------------+---------------+----------------------------------------------------
 id             | integer       | not null default nextval('tasks_id_seq'::regclass)
 taskid         | character(32) | not null
 time           | integer       | 
 threat         | integer       | 
Indexes:
    "tasks_pkey" PRIMARY KEY, btree (id)
    "tasks_taskid_key" UNIQUE CONSTRAINT, btree (taskid)
    "tasks_taskid_index" btree (taskid)
    "tasks_time_index" btree ("time")
Referenced by:
    TABLE "alert_detail" CONSTRAINT "alert_detail_taskid_fkey" FOREIGN KEY (taskid) REFERENCES tasks(taskid) ON DELETE CASCADE
Triggers:
    after_del AFTER DELETE ON tasks FOR EACH ROW EXECUTE PROCEDURE fileref_auto_decrease()

Запрос: (после «SET enable_seqscan = Off;» и «проанализировать задачи;») 

# explain (analyze,buffers)  select * from tasks order by time desc limit 2;
                                                                   QUERY PLAN                                                                

---------------------------------------------------------------------------------------------------------------------------------------------
----
 Limit  (cost=10000729745.02..10000729745.02 rows=2 width=668) (actual time=20602.895..20602.896 rows=2 loops=1)
   Buffers: shared hit=457 read=592336
   ->  Sort  (cost=10000729745.02..10000746864.02 rows=6847601 width=668) (actual time=20602.894..20602.895 rows=2 loops=1)
         Sort Key: "time"
         Sort Method: top-N heapsort  Memory: 27kB
         Buffers: shared hit=457 read=592336
         ->  Seq Scan on tasks  (cost=10000000000.00..10000661269.01 rows=6847601 width=668) (actual time=0.003..18939.268 rows=6847881 loops
=1)
               Buffers: shared hit=457 read=592336
 Planning time: 0.094 ms
 Execution time: 20602.930 ms

1 Ответ

0 голосов
/ 01 июня 2018

Я решил эту проблему, возможно, причина в том, что у postgres в A недостаточно памяти, все нормально после перезапуска службы postgresql.Я думаю, что нагрузка B будет лучше, чем A

...