Создание индекса GIST на PostgreSQL слишком медленное - PullRequest
0 голосов
/ 02 июля 2019

У меня есть база данных в PostgreSQL со следующей структурой:

Column    |         Type          | Collation | Nullable |                    Default                     
-------------+-----------------------+-----------+----------+------------------------------------------------
 vessel_hash | integer               |           | not null | nextval('samplecol_vessel_hash_seq'::regclass)
 status      | character varying(50) |           |          | 
 station     | character varying(50) |           |          | 
 speed       | character varying(10) |           |          | 
 longitude   | numeric(12,8)         |           |          | 
 latitude    | numeric(12,8)         |           |          | 
 course      | character varying(50) |           |          | 
 heading     | character varying(50) |           |          | 
 timestamp   | character varying(50) |           |          | 
 the_geom    | geometry              |           |          | 
Check constraints:
    "enforce_dims_the_geom" CHECK (st_ndims(the_geom) = 2)
    "enforce_geotype_geom" CHECK (geometrytype(the_geom) = 'POINT'::text OR the_geom IS NULL)
    "enforce_srid_the_geom" CHECK (st_srid(the_geom) = 4326)

База данных содержит ~ 146.000.000 записей, а размер таблицы, содержащей данные:

public | samplecol   | table    | postgres | 31 GB      | 

Я пытаюсь создать индекс GIST для поля геометрии the_geom с помощью этой команды:

create index samplecol_the_geom_gist on samplecol using gist (the_geom);

, но это занимает слишком много времени.Он работает уже 2 часа.

На основании этого вопроса Медленная индексация таблицы Postgis на 300 ГБ. Задайте вопрос , перед созданием индекса я выполняю в консоли psql:

ALTER SYSTEM SET maintenance_work_mem = '1GB'; 
ALTER SYSTEM


SELCT pg_reload_conf();

pg_reload_conf 
----------------  
t 
(1 row)

НоСоздание индекса занимает слишком много времени.Кто-нибудь знает почему?А как это исправить?

1 Ответ

1 голос
/ 02 июля 2019

Боюсь, вам придется смириться с этим.

Помимо высоких maintenance_work_mem, на самом деле не существует варианта настройки.Увеличение max_wal_size немного поможет, так как вы получите меньше контрольных точек.

Если вы не можете долго жить с блокировкой ACCESS EXCLUSIVE, попробуйте CREATE INDEX CONCURRENTLY, который будет еще медленнее, но выигралне блокировать одновременную активность базы данных.

...