Skip site navigation (1) Skip section navigation (2)

Re: TB-sized databases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: pgsql-performance(at)postgreSQL(dot)org
Subject: Re: TB-sized databases
Date: 2007-12-07 04:14:10
Message-ID: 10359.1197000850@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> Tom Lane wrote:
>> There's something fishy about this --- given that that plan has a lower
>> cost estimate, it should've picked it without any artificial
>> constraints.

> I think the reason it's not picking it was discussed back in this thread
> too.
> http://archives.postgresql.org/pgsql-performance/2005-03/msg00675.php
> http://archives.postgresql.org/pgsql-performance/2005-03/msg00684.php
> My offset 0 is forcing the outer join.
> [Edit: Ugh - meant cartesian join - which helps this kind of query.]

Ah; I missed the fact that the two relations you want to join first
don't have any connecting WHERE clause.

The concern I mentioned in the above thread was basically that I don't
want the planner to go off chasing Cartesian join paths in general ---
they're usually useless and would result in an exponential explosion
in the number of join paths considered in many-table queries.

However, in this case the reason that the Cartesian join might be
relevant is that both of them are needed in order to form an inner
indexscan on the big table.  I wonder if we could drive consideration
of the Cartesian join off of noticing that.  It'd take some rejiggering
around best_inner_indexscan(), or somewhere in that general vicinity.

Way too late for 8.3, but something to think about for next time.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Ron MayerDate: 2007-12-07 05:11:40
Subject: Re: TB-sized databases
Previous:From: Ron MayerDate: 2007-12-07 03:55:17
Subject: Re: TB-sized databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group