стоимость снизилась, но время было практически таким же, почему? - PullRequest
1 голос
/ 02 мая 2019

Определение таблицы:

CREATE TABLE schema.mylogoperation (
  id_mylogoperation serial,
  data DATE,
  myschema VARCHAR(255),
  column_var_2 VARCHAR(255),
  user VARCHAR(255),
  action TEXT,
  column_var_1 TEXT,
  log_old VARCHAR,
  log_new VARCHAR
  constraint pk_mylogoperation primary key (id_mylogoperation)
) 
WITH (oids = false);
  • 12 миллионов строк

Я пытался объяснить, проанализировать:

explain analyze
SELECT
    column_var_1,
    column_var_2
    column_var_3,
    user,
    action,
    data,
    log_old,
    log_new
FROM schema.mylogoperation
WHERE
    myschema = 'schema'
AND column_var_2 IN ('mydata1', 'mydata2', 'mydata3')
AND log_old <> log_new
AND column_var_1 LIKE 'mydata%';

indexes ( pk_mylogoperation only)
QUERY PLAN
Seq Scan on myschema  (cost=0.00..713948.14rows=660 width=222) (actual time=380.308..4467.364 rows=48 loops=1)
  Filter: (((log_old)::text <> (log_new)::text) AND (column_var_1 ~~ 'mydata%'::text) AND ((schema)::text = 'schema'::text) AND ((column_var_2)::text = ANY ('{mydata1,mydata2,mydata3}'::text[])))
  Rows Removed by Filter: 12525296
Total runtime: 4467.425 ms

Затем я попытался создать некоторый индекс для лучшей производительности:

CREATE INDEX idx_mylogoperation_1    ON schema.mylogoperation (myschema, column_var_2);

reindex table schema.mylogoperation;
analyze schema.mylogoperation;

pk_mylogoperation + idx_mylogoperation_1
QUERY PLAN
Index Scan using idx_mylogoperation_qry1 on mylogoperation  (cost=0.56..589836.84 rows=658 width=223) (actual time=331.679..4997.507 rows=48 loops=1)
  Index Cond: (((myschema)::text = 'schema'::text) AND ((column_var_2)::text = ANY ('{mydata1,mydata2,mydata3}'::text[])))
  Filter: (((log_old)::text <> (log_new)::text) AND (column_var_1 ~~ 'mydata%'::text))
  Rows Removed by Filter: 7441986
Total runtime: 4997.580 ms

Затем я снова попытался создать некоторый индекс для повышения производительности:

CREATE INDEX idx_mylogoperation_2 ON schema.mylogoperation USING gin (column_var_1 gin_trgm_ops);

reindex table schema.mylogoperation;
analyze schema.mylogoperation;

pk_mylogoperation + idx_mylogoperation_1 + idx_mylogoperation_2
QUERY PLAN
Bitmap Heap Scan on idx_mylogoperation_var_1  (cost=1398.58..2765.08 rows=663 width=222) (actual time=5303.481..5303.906 rows=48 loops=1)
  Recheck Cond: (column_var_1 ~~ 'mydata%'::text)
  Filter: (((log_old)::text <> (log_new)::text) AND ((myschema)::text = 'schema'::text) AND ((column_var_2)::text = ANY ('{mydata1,mydata2,mydata3}'::text[])))
  Rows Removed by Filter: 248
  ->  Bitmap Index Scan on idx_mylogoperation_var_1  (cost=0.00..1398.41 rows=1215 width=0) (actual time=5303.203..5303.203 rows=296 loops=1)
        Index Cond: (column_var_1 ~~ 'mydata%'::text)
Total runtime: 5303.950 ms

Вопрос

  • стоимость снизилась, но время практически не изменилось, почему?

Примечания

  • Я не хочу вносить изменения в операцию выбора, просто в структуру базы данных.

  • Этот тест был выполнен на сервере, который используется. Но создание этих показателей было эффективным? Вернее, не используйте их.

  • Я использую Postgres 9.3.22 в Linux 64-bit Red Hat.

1 Ответ

1 голос
/ 02 мая 2019

Этот индекс:

CREATE INDEX idx_mylogoperation_1    ON schema.mylogoperation (myschema, column_var_2);

не помогло, потому что соответствующая часть вашего предложения where соответствовала ~ 2/3 таблицы. Индекс не очень сузил результаты, но фильтр сделал:

Filter: (((log_old)::text <> (log_new)::text) AND (column_var_1 ~~ 'mydata%'::text))
  Rows Removed by Filter: 7441986

Я не уверен, какая из этих двух вещей в фильтре удалена больше, но вы можете попробовать частичный индекс, такой как:

CREATE INDEX idx_mylogoperation_1    ON schema.mylogoperation (myschema, column_var_2) WHERE log_old <> log_new;
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...