Re: Should Oracle outperform PostgreSQL on a complex

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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 16:43:15
Message-ID: 200512171643.jBHGhFA04982@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-12-17 18:13:42 Re: Should Oracle outperform PostgreSQL on a complex
Previous Message Bruce Momjian 2005-12-17 14:56:49 Re: Simple Join