Редагувати:
З вибаченнями, мені потрібно відмовитись від твердження, що прийнята відповідь не завжди є правильною - в ній сказано, що погляд завжди ідентичний тому ж, що написано як підзапит. Я думаю, що це незаперечно, і я думаю, що зараз знаю, що відбувається в моєму випадку.
Я також думаю, що є краща відповідь на початкове запитання.
Первісне питання полягає в тому, чи слід керувати практикою використання поглядів (на відміну, наприклад, повторення SQL у підпрограмах, які, можливо, потрібно буде підтримувати двічі і більше).
Моєю відповіддю було б "не, якщо ваш запит використовує віконні функції чи що-небудь інше, що змушує оптимізатора по-різному ставитись до запиту, коли він стає підзапитом, тому що сам акт створення підзапиту (представляється він як перегляд чи ні) може погіршити ефективність якщо ви фільтруєте з параметрами під час виконання.
Складність функції мого вікна зайва. Поясніть план цього:
SELECT DISTINCT ts.train_service_key,
pc.assembly_key,
count(*) OVER
(PARTITION BY ts.train_service_key) AS train_records
FROM staging.train_service ts
JOIN staging.portion_consist pc
USING (ds_code, train_service_key)
WHERE assembly_key = '185132';
набагато дешевше, ніж для цього:
SELECT *
FROM (SELECT DISTINCT ts.train_service_key,
pc.assembly_key,
count(*) OVER
(PARTITION BY ts.train_service_key) AS train_records
FROM staging.train_service ts
JOIN staging.portion_consist pc
USING (ds_code, train_service_key)) AS query
WHERE assembly_key = '185132';
Сподіваюся, це трохи конкретніше та корисніше.
З мого недавнього досвіду (змушує мене знайти це питання), прийнята відповідь вище не коректна за будь-яких обставин. У мене порівняно простий запит, який включає функцію вікна:
SELECT DISTINCT ts.train_service_key,
pc.assembly_key,
dense_rank() OVER (PARTITION BY ts.train_service_key
ORDER BY pc.through_idx DESC, pc.first_portion ASC,
((CASE WHEN (NOT ts.primary_direction)
THEN '-1' :: INTEGER
ELSE 1
END) * pc.first_seq)) AS coach_block_idx
FROM (staging.train_service ts
JOIN staging.portion_consist pc USING (ds_code, train_service_key))
Якщо я додаю цей фільтр:
where assembly_key = '185132'
План пояснення, який я отримую, такий:
QUERY PLAN
Unique (cost=11562.66..11568.77 rows=814 width=43)
-> Sort (cost=11562.66..11564.70 rows=814 width=43)
Sort Key: ts.train_service_key, (dense_rank() OVER (?))
-> WindowAgg (cost=11500.92..11523.31 rows=814 width=43)
-> Sort (cost=11500.92..11502.96 rows=814 width=35)
Sort Key: ts.train_service_key, pc.through_idx DESC, pc.first_portion, ((CASE WHEN (NOT ts.primary_direction) THEN '-1'::integer ELSE 1 END * pc.first_seq))
-> Nested Loop (cost=20.39..11461.57 rows=814 width=35)
-> Bitmap Heap Scan on portion_consist pc (cost=19.97..3370.39 rows=973 width=38)
Recheck Cond: (assembly_key = '185132'::text)
-> Bitmap Index Scan on portion_consist_assembly_key_index (cost=0.00..19.72 rows=973 width=0)
Index Cond: (assembly_key = '185132'::text)
-> Index Scan using train_service_pk on train_service ts (cost=0.43..8.30 rows=1 width=21)
Index Cond: ((ds_code = pc.ds_code) AND (train_service_key = pc.train_service_key))
Для цього використовується індекс первинного ключа в таблиці служб поїздів і не унікальний індекс таблиці por_consist. Він виконується за 90мс.
Я створив подання (вставивши його тут, щоб він був абсолютно зрозумілим, але це буквально запит у представленні):
CREATE OR REPLACE VIEW staging.v_unit_coach_block AS
SELECT DISTINCT ts.train_service_key,
pc.assembly_key,
dense_rank() OVER (PARTITION BY ts.train_service_key
ORDER BY pc.through_idx DESC, pc.first_portion ASC, (
(CASE
WHEN (NOT ts.primary_direction)
THEN '-1' :: INTEGER
ELSE 1
END) * pc.first_seq)) AS coach_block_idx
FROM (staging.train_service ts
JOIN staging.portion_consist pc USING (ds_code, train_service_key))
Коли я запитую цей вид з однаковим фільтром:
select * from staging.v_unit_coach_block
where assembly_key = '185132';
Це план пояснення:
QUERY PLAN
Subquery Scan on v_unit_coach_block (cost=494217.13..508955.10 rows=3275 width=31)
Filter: (v_unit_coach_block.assembly_key = '185132'::text)
-> Unique (cost=494217.13..500767.34 rows=655021 width=43)
-> Sort (cost=494217.13..495854.68 rows=655021 width=43)
Sort Key: ts.train_service_key, pc.assembly_key, (dense_rank() OVER (?))
-> WindowAgg (cost=392772.16..410785.23 rows=655021 width=43)
-> Sort (cost=392772.16..394409.71 rows=655021 width=35)
Sort Key: ts.train_service_key, pc.through_idx DESC, pc.first_portion, ((CASE WHEN (NOT ts.primary_direction) THEN '-1'::integer ELSE 1 END * pc.first_seq))
-> Hash Join (cost=89947.40..311580.26 rows=655021 width=35)
Hash Cond: ((pc.ds_code = ts.ds_code) AND (pc.train_service_key = ts.train_service_key))
-> Seq Scan on portion_consist pc (cost=0.00..39867.86 rows=782786 width=38)
-> Hash (cost=65935.36..65935.36 rows=1151136 width=21)
-> Seq Scan on train_service ts (cost=0.00..65935.36 rows=1151136 width=21)
Це робить повне сканування обох таблиць і займає 17 секунд.
Поки я не натрапив на це, я широко використовував погляди з PostgreSQL (розуміючи широко поширені погляди, виражені у прийнятій відповіді). Я спеціально уникаю використання представлень, якщо мені потрібна попередня сукупність фільтрації, для якої я б використовував функції повернення набору.
Я також знаю, що CTE в PostgreSQL суворо оцінюються окремо, тому я не використовую їх так само, як це було б, наприклад, із SQL Server, де вони, схоже, оптимізовані як підзапити.
Моя відповідь, отже, є випадки, коли погляди виконують не так, як запит, на якому вони ґрунтуються, тому рекомендується обережність. Я використовую Amazon Aurora на основі PostgreSQL 9.6.6.
SELECT * FROM my_view WHERE my_column = 'blablabla';.При другому йдеться про використання подань, щоб зробити вашу модель даних прозорою для програми, яка її використовує. Перші джерела вказують на те, що ви включите фільтрWHERE my_column = 'blablabla'всередину визначення перегляду, оскільки це призводить до кращого плану виконання.