Эффективны ли простые вложенные представления (при условии отсутствия лишних таблиц?)

Question

• 1000 *

https://dba.stackexchange.com/questions/151169/are-views-harmful-for-performance-in-postgresql

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

Предположим, у меня есть представление:

create view A as
select
  x.xKey,
  x.y,
  x.z,
  y.yKey,
  y.a,
  y.b
from x
join y
  on x.xKey = y.xKey

А теперь у меня есть другое ...

create view B as
select
  A.xKey,
  A.y,
  A.z,
  A.yKey,
  A.a,
  A.b,
  r.rKey,
  r.n
from A
join r
  on A.yKey = r.yKey 

Предположим, что третье представление C делает больше то же самое, но все три представления представляют собой простые операторы выбора.

Два вопроса:

1. Если я выберу из представления C с использованием фильтров, которые относятся к любому / всем из задействованные таблицы - это «предикаты», которые всегда «опускаются» (новая фраза для меня, надеюсь, я сказал это правильно), так что представление C с точки зрения фильтрации столь же эффективно, как и более крупный автономный запрос, построенный таким же образом ?

2. Если я выберу из представления C, но я не использую все таблицы, участвующие во всех o Если говорить о соединениях, то здесь я действительно плачу цену, которой можно было бы избежать с помощью созданного вручную оператора select, объединяющего меньшее количество таблиц. Да?

Заранее большое спасибо за мысли.

Answer 1

Эксперты могут поправить меня по этому поводу.

Я не мастер читать операторы EXPLAIN, но я могу вырезать и вставить SQL очень хорошо, и я могу довольно хорошо читать секундомер.

Я здесь, чтобы сказать.

Встроенные представления, даже простые, могут внести СЕРЬЕЗНУЮ боль в скорости выполнения.

Я только что ответил на свой вопрос, работая с представлением G то есть (или было) что-то похожее (используя мою аналогию A, B, C, изложенную в OP), выбор из представления F, который использует E ... до A.

Выбор результатов для одна отфильтрованная строка занимала слишком много времени - порядка 500 мсек.

Я уменьшил это время до 200 мс, уменьшив количество дополнительных таблиц, захватываемых по ходу. Никакого шока, что я там кое-что приобрел. Немного шокирует, увидев, сколько.

Но затем я уменьшил эти 200 мс до 7 мс, заменив представление G на использование представления B и вместо этого используя конструкцию B как часть представления G. существенно сложнее для чтения, но потрясающе эффективнее.

Вот и все, что нужно для абстрагирования от общих объединений.

Итак, это ответ на мой первый вопрос решительным НЕТ! В PostgreSQL представление, использующее вложенные представления, может быть шокирующе МЕНЬШЕ эффективным, чем логически эквивалентное представление, которое вообще не использует вложенности.

Мой вывод: если производительность падает, НЕ предполагайте, что ваши вложенные представления невиновен. Они могут ОЧЕНЬ вероятно причинить вам боль.

Плохо.

PS Я начинаю понимать, как читать результаты EXPLAIN. Кикер состоит в том, что вложенное представление объясняется следующим образом ...

->  Hash Join  (cost=20902.62..28364.33 rows=1 width=1018)
      (actual time=878.007..1092.339 rows=0 loops=3)
        Hash Cond: (mi.mft_item_id = ri.mft_item_id)

, тогда как мое мнение, которое избегает использования вложенного представления, сняло это ...

->  Index Scan using mft_items_pkey on mft_items mi
      (cost=0.42..8.44 rows=1 width=187)
      (actual time=0.024..0.024 rows=1 loops=1)
        Index Cond: (mft_item_id = ri.mft_item_id)

Postre SQL не использовал желаемые индексы, когда я объединил два представления вместе.