From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Pål Stenslet <paal(dot)stenslet(at)exie(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Should Oracle outperform PostgreSQL on a complex |
Date: | 2005-12-17 09:15:53 |
Message-ID: | 1134810953.2964.117.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
> How are star joins different from what we do now?
Various ways of doing them, but all use plans that you wouldn't have
come up with via normal join planning.
Methods:
1. join all N small tables together in a cartesian product, then join to
main Large table once (rather than N times)
2. transform joins into subselects, then return subselect rows via an
index bitmap. Joins are performed via a bitmap addition process.
You can fake (1) yourself with a temporary table, and the basics for (2)
are now in place also.
The characteristics of these joins make them suitable for large Data
Warehouses with Fact-Dimension style designs.
Many RDBMS have this, but we need to be careful of patent claims. I'm
sure there's a way through that, but I'm not looking for it yet. Anybody
else wishing to assist with a detailed analysis would be much
appreciated.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2005-12-17 12:31:40 | Re: Overriding the optimizer |
Previous Message | David Lang | 2005-12-17 08:40:51 | Re: Overriding the optimizer |