Как использовать базовый индекс при фильтрации VIEW?

Question

У меня очень простой запрос, который выполнялся на удивление медленно, и по причинам выяснилось, что он выполнял сканирование представления после выполнения JOIN.Я был немного удивлен, увидев, что, поскольку я ожидал, что Postgres выполнит фильтрацию до присоединения , я увидел, что одна из базовых таблиц имеет INDEX для столбца, который должен быть отфильтрован.

Есть ли способ, которым я могу как-то переупорядочить запрос или подсказать планировщику, как выполнить запрос по-другому?

Имейте в виду, я делаю знаю, как взломать проблему напрямуюдоступ к базовым таблицам, но представление скрывает некоторую сложность, было бы неплохо не указывать в запросах.

Запрос

select * from form where encounter_id= 23728 and type = 'vitals';

EXPLAIN ANALYZE

Subquery Scan on form  (cost=0.57..3439.07 rows=1 width=622) (actual time=8.187..8.187 rows=0 loops=1)
  Filter: ((form.encounter_id = 23728) AND (form.type = 'vitals'::text))
  Rows Removed by Filter: 12000
  ->  Unique  (cost=0.57..3259.07 rows=12000 width=626) (actual time=0.008..7.612 rows=12000 loops=1)
        ->  Merge Join  (cost=0.57..3229.07 rows=12000 width=626) (actual time=0.007..5.485 rows=12000 loops=1)
              Merge Cond: (fd.form_id = f.id)
              ->  Index Scan using _idx_form_details on _form_details fd  (cost=0.29..2636.78 rows=12000 width=603) (actual time=0.003..1.918 rows=12000 loops=1)
              ->  Index Scan using pk_form on _form f  (cost=0.29..412.29 rows=12000 width=27) (actual time=0.002..1.214 rows=12000 loops=1)
Planning time: 0.170 ms
Execution time: 8.212 ms

Определения TABLE и VIEW

CREATE TABLE _form (
  id INT NOT NULL,
  encounter_id INT REFERENCES _encounter (id)            NOT NULL,
  type         TEXT                                      NOT NULL,
  CONSTRAINT pk_form PRIMARY KEY (id),
  FOREIGN KEY (cid) REFERENCES _user_in_role (id)
);

CREATE INDEX encounter_id ON _form (encounter_id, type);

CREATE TABLE _form_details (
  id INT NOT NULL,
  form_id   INT REFERENCES _form (id) NOT NULL,
  archived  BOOLEAN                   NOT NULL DEFAULT FALSE,
  CONSTRAINT pk_form_details PRIMARY KEY (id),
  FOREIGN KEY (cid) REFERENCES _user_in_role (id)
);

CREATE VIEW form AS
  SELECT DISTINCT ON (f.id)
    f.id,
    f.encounter_id,
    f.type,
    fd.archived,
    f.cid
  FROM _form f 
       JOIN _form_details fd 
         ON (f.id = fd.form_id)
  ORDER BY f.id, fd.id DESC;

РЕДАКТИРОВАТЬ: Кто-то отправил ответ (впоследствии удален), которая содержала важный фрагмент информации: даже если столбец encounter_id в базовой таблице проиндексирован, операция ORDER BY в VIEW не отвечает своей цели.К сожалению, мы не можем избавиться от ORDER BY, поскольку это необходимо для работы DISTINCT ON.

Answer 1

@ a_horse_with_no_name дал мне самое быстрое решение в чате, но так и не дал ответа.Итак, для справки, вот его решение, использующее боковое соединение для создания вида.

CREATE VIEW form AS
    SELECT f.id, 
        f.encounter_id, 
        f.type, 
        fd.archived, 
        f.cid 
    FROM _form f 
    JOIN LATERAL ( 
        SELECT form_id, archived 
        FROM _form_details _fd 
        WHERE _fd.form_id = f.id 
        ORDER BY _fd.id DESC 
        LIMIT 1 
    ) AS fd ON TRUE; 

Это примерно в 10 раз быстрее , чем любые другие решения.Если он создан как form4, основываясь на тех же таблицах, что и таблицы из @wildplasser, то вот как он работает:

select * from form where encounter_id= 23728 and ztype = 'vitals' ;
Time: 181.065 ms
select * from form2 where encounter_id= 23728 and ztype = 'vitals' ;
Time: 12.395 ms
select * from form3 where encounter_id= 23728 and ztype = 'vitals' ;
Time: 122.305 ms
select * from form4 where encounter_id= 23728 and ztype = 'vitals' ;
Time: 1.305 ms

Несколько хороших указателей на боковые объединения, представленные в Postgres 9.3:

• https://medium.com/kkempin/postgresqls-lateral-join-bfd6bd0199df
• https://heapanalytics.com/blog/engineering/postgresqls-powerful-new-join-type-lateral
• В чем разница между LATERAL и подзапросом в PostgreSQL?

Answer 2

• DISTINCT ON ... ORDER BY - убийца производительности (подзапрос не может быть разбит)
• отсутствует индекс для form_id INT REFERENCES _form (id) FK
• a NOT EXISTS() antijoinили row_number() можно использовать, чтобы избежать подзапроса DISTINCT

---

SET search_path=tmp;
/***/
\i tmp.sql

CREATE TABLE tform (
  id INT NOT NULL
  , encounter_id INT NOT NULL -- REFERENCES tencounter (id)
  , ztype         TEXT                                      NOT NULL
  , CONSTRAINT pk_form PRIMARY KEY (id)
  -- FOREIGN KEY (cid) REFERENCES _user_in_role (id)
);

CREATE TABLE tform_details (
  id INT NOT NULL
  , form_id   INT REFERENCES tform (id) NOT NULL
  , archived  BOOLEAN                   NOT NULL DEFAULT FALSE
  , CONSTRAINT pk_form_details PRIMARY KEY (id)
  -- , FOREIGN KEY (cid) REFERENCES _user_in_role (id)
);

-- ALTER TABLE tform ADD FOREIGN KEY(encounter_id) REFERENCES tencounter (id) ;
CREATE INDEX encounter_id ON tform (encounter_id, ztype);

INSERT INTO tform (id, encounter_id, ztype)
SELECT gs, 23720+gs%29, 'ztype_' || gs::text
FROM generate_series(1,10000) gs
        ;

INSERT INTO tform_details (id, form_id, archived)
SELECT 10000*gs+tf.id, tf.id, (random() > 0.3) ::boolean
FROM tform tf
CROSS JOIN generate_series(0,22) gs
        ;


UPDATE tform
SET ztype = 'vitals'
WHERE random() < 0.2;

/***/
DROP INDEX xxxx ;
CREATE UNIQUE INDEX xxxx ON tform_details (form_id, id);

VACUUM ANALYZE tform;
VACUUM ANALYZE tform_details;

\d tform;
\d tform_details;

select COUNT(*) FROM tform;
select COUNT(*) FROM tform_details;

DROP VIEW form ;
CREATE VIEW form AS
  SELECT DISTINCT ON (f.id)
    f.id
    , f.encounter_id
    , f.ztype
    , fd.archived
    -- , f.cid
  FROM tform f
       JOIN tform_details fd ON f.id = fd.form_id
  ORDER BY f.id, fd.id DESC
        ;

DROP VIEW form2 ;
CREATE VIEW form2 AS
  SELECT f.id
    , f.encounter_id
    , f.ztype
    , fd.archived
  FROM tform f
  JOIN tform_details fd
    ON f.id = fd.form_id
  WHERE NOT EXISTS ( SELECT *
        FROM tform_details nx
        WHERE nx.form_id = fd.form_id
        AND nx.id > fd.id
        )
        ;

DROP VIEW form3 ;
CREATE VIEW form3 AS
  SELECT f.id
    , f.encounter_id
    , f.ztype
    , fd.archived
  FROM tform f
  JOIN ( select xx.form_id, xx.archived
        , row_number() OVER (PARTITION BY xx.form_id ORDER BY xx.id DESC) AS rn
         FROM tform_details xx
        ) fd ON f.id = fd.form_id AND fd.rn = 1
        ;

\echo burn-in
EXPLAIN ANALYZE
select * from form where encounter_id= 23728 and ztype = 'vitals' ;

\echo plain
EXPLAIN ANALYZE
select * from form where encounter_id= 23728 and ztype = 'vitals' ;

EXPLAIN ANALYZE
select * from form2 where encounter_id= 23728 and ztype = 'vitals' ;

EXPLAIN ANALYZE
select * from form3 where encounter_id= 23728 and ztype = 'vitals' ;

\echo no_hash
SET enable_hashjoin = False;

EXPLAIN ANALYZE
select * from form where encounter_id= 23728 and ztype = 'vitals' ;

EXPLAIN ANALYZE
select * from form2 where encounter_id= 23728 and ztype = 'vitals' ;

EXPLAIN ANALYZE
select * from form3 where encounter_id= 23728 and ztype = 'vitals' ;