Re: [SQL] Nested Views take forever

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [SQL] Nested Views take forever
Дата
Msg-id 21836.942366846@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Nested Views take forever  ("Zot O'Connor" <zot@zotconsulting.com>)
Ответы Re: [SQL] Nested Views take forever
Список pgsql-sql
"Zot O'Connor" <zot@zotconsulting.com> writes:
> consup=> EXPLAIN SELECT COUNT(*) from depth3;
> NOTICE:  QUERY PLAN:
> Aggregate  (cost=11.69 rows=233 width=4)
>   ->  Seq Scan on subcat  (cost=11.69 rows=233 width=4)
>         SubPlan
>           ->  Seq Scan on subcat  (cost=11.69 rows=233 width=4)
>                 SubPlan
>                   ->  Seq Scan on subcat  (cost=11.69 rows=6 width=4)

The problem here is not views per se, it's that WHERE x in (sub-select)
is not a very efficient construct --- it basically always generates a
nested-loop plan.  What you've got above is O(N^3) for an N-tuple table.

Try something like this instead:

CREATE VIEW depth2 AS SELECT ... FROM subcat, depth1 WHEREsubcat.scatscat = depth1.scatval;

CREATE VIEW depth3 AS SELECT ... FROM subcat, depth2 WHEREsubcat.scatscat = depth2.scatval;

Given indexes on scatscat and scatval, I'd expect this to produce a
merge-join plan, which should be reasonably quick --- better than
O(N^2) or O(N^3) anyway.

There's been some talk of reimplementing WHERE ... IN ... so that it
does something intelligent without help, but there are a lot of
higher-priority problems on the TODO list...
        regards, tom lane


В списке pgsql-sql по дате отправления:

Предыдущее
От: "Zot O'Connor"
Дата:
Сообщение: Nested Views take forever
Следующее
От: " Дата:
Сообщение: Rules and referential integrity