[EMAIL PROTECTED] writes:
Unfortunately, yes thats true - thats is for correctness, not an
optimization decision. Outer joins constrain you on both join order AND
on join type. Nested loops and hash joins avoid touching all rows in
the right hand table, which is exactly what you don't want
; but look, and pass on.
- Original Message -
From: Gabriele Bartolini [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 5:36 PM
Subject: [PERFORM] Data warehousing requirements
Hi guys,
I just discussed about my problem on IRC. I am building a Web usage
At 13.30 07/10/2004, Aaron Werman wrote:
Consider how the fact table is going to be used, and review hacking it up
based on usage. Fact tables should be fairly narrow, so if there are extra
columns beyond keys and dimension keys consider breaking it into parallel
tables (vertical partitioning).
Tom,
Well, I sit corrected. Obviously I misread that.
It's not so much that they are necessarily inefficient as that they
constrain the planner's freedom of action. You need to think a lot more
carefully about the order of joining than when you use inner joins.
I've also found that OUTER
Hi guys,
I just discussed about my problem on IRC. I am building a Web usage
mining system based on Linux, PostgreSQL and C++ made up of an OLTP
database which feeds several and multi-purpose data warehouses about users'
behaviour on HTTP servers.
I modelled every warehouse using the
