From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zot O'Connor" <zot(at)zotconsulting(dot)com> |
Cc: | postgres sql <pgsql-sql(at)hub(dot)org> |
Subject: | Re: [SQL] Nested Views take forever |
Date: | 1999-11-12 00:34:06 |
Message-ID: | 21836.942366846@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Zot O'Connor" <zot(at)zotconsulting(dot)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 WHERE
subcat.scatscat = depth1.scatval;
CREATE VIEW depth3 AS SELECT ... FROM subcat, depth2 WHERE
subcat.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
From | Date | Subject | |
---|---|---|---|
Next Message | marten | 1999-11-12 07:42:26 | Re: [SQL] Nested Views take forever |
Previous Message | Zot O'Connor | 1999-11-11 23:10:09 | Nested Views take forever |