From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Pål Stenslet <paal.stenslet@exie.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Should Oracle outperform PostgreSQL on a complex
Date: Sat, 17 Dec 2005 11:43:15 -0500 (EST)
Message-ID: <200512171643.jBHGhFA04982@candle.pha.pa.us> (raw)
In-Reply-To: <1134810953.2964.117.camel@localhost.localdomain>
OK, so while our bitmap scan allows multiple indexes to be joined to get
to heap rows, a star joins allows multiple dimensions _tables_ to be
joined to index into a larger main fact table --- interesting.
Added to TODO:
* Allow star join optimizations
While our bitmap scan allows multiple indexes to be joined to get
to heap rows, a star joins allows multiple dimension _tables_ to
be joined to index into a larger main fact table. The join is
usually performed by either creating a cartesian product of all
the dimmension tables and doing a single join on that product or
using subselects to create bitmaps of each dimmension table match
and merge the bitmaps to perform the join on the fact table.
---------------------------------------------------------------------------
Simon Riggs wrote:
> 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
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pgman@candle.pha.pa.us, simon@2ndquadrant.com, paal.stenslet@exie.com
Subject: Re: Should Oracle outperform PostgreSQL on a complex
In-Reply-To: <200512171643.jBHGhFA04982@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox