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 по дате отправления: