Tom Lane <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
> >> How are star joins different from what we do now?
>
> > Methods:
> > 1. join all N small tables together in a cartesian product, then join to
> > main La
I have the following table:
CREATE TABLE timeblock
(
timeblockid int8 NOT NULL,
starttime timestamp,
endtime timestamp,
duration int4,
blocktypeid int8,
domain_id int8,
create_date timestamp,
revision_date timestamp,
scheduleid int8,
CONSTRAINT timeblock_pkey PRIMARY KEY (timeb
Tom Lane wrote:
2. transform joins into subselects, then return subselect rows via an
index bitmap. Joins are performed via a bitmap addition process.
Looks like 8.1 pretty much does this right now:
First the basic star:
EXPLAIN ANALYZE
SELECT
d0.dmth,
d1.dat,
count(f
On Sun, Dec 18, 2005 at 02:11:16AM +, Harry Jackson wrote:
> The one thing that may be skewing these results is that this was
> compiled and installed from source with
>
> ./configure CFLAGS='-O2' --with-openssl --enable-thread-safety
>
> I am not sure what the default Debian binary for 7.4.7
On 12/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> PostgreSQL 8.1.1 should give you greater performance...
Indeed it has.
I am seeing a 25% increase in one particular select statement. This
increases to 32% with
set enable_bitmapscan to off;
I also ran a test script full of commo
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
How are star joins different from what we do now?
Methods:
1. join all N small tables together in a cartesian product, then join to
main Large table once (rather than N times)
Tom,
On 12/17/05 10:47 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> BTW, some experimentation suggests that in fact a star join is already
> slower than the "regular" plan in 8.1. You can force a star-join plan
> to be generated like this:
Cool!
We've got Paal's test case in the queue to run, i
Tom Lane wrote:
> Bruce Momjian writes:
> > Added to TODO:
> > * Allow star join optimizations
>
> See my response to Simon for reasons why this doesn't seem like a
> particularly good TODO item.
Yes, TODO removed. I thought we were waiting for bitmap joins before
trying star joins. I did not
I wrote:
> However, I submit that it wouldn't pick such a plan anyway, and should
> not, because the idea is utterly stupid.
BTW, some experimentation suggests that in fact a star join is already
slower than the "regular" plan in 8.1. You can force a star-join plan
to be generated like this:
reg
Bruce Momjian writes:
> Added to TODO:
> * Allow star join optimizations
See my response to Simon for reasons why this doesn't seem like a
particularly good TODO item.
regards, tom lane
---(end of broadcast)---
TIP 4: Have
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
>> How are star joins different from what we do now?
> Methods:
> 1. join all N small tables together in a cartesian product, then join to
> main Large table once (rather than N times)
Of course, the
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 ind
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I'm running 8.1 installed from source on a Debian Sarge server. I have a
> > simple query that I believe I've placed the indexes correctly for, and I
> > still end up with a seq scan. It makes sense, kinda, but it should be able
> >
> > Yeah it would - an implementation I have seen that I like is where the
> > developer can supply the *entire* execution plan with a query. This is
> > complex enough to make casual use unlikely :-), but provides the ability
> > to try out other plans, and also fix that vital query that must run
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
On Fri, 16 Dec 2005, Mark Kirkwood wrote:
Craig A. James wrote:
What would be cool would be some way the developer could alter the plan,
but they way of doing so would strongly encourage the developer to send the
information to this mailing list. Postgres would essentially say, "Ok, you
c
16 matches
Mail list logo