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

Re: TB-sized databases

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: TB-sized databases
Date: 2008-03-17 23:47:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I have _not_ added a TODO for this item.  Let me know if one is needed.


Tom Lane wrote:
> 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.
> >
> >
> > 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
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2008-03-18 00:28:50
Subject: Re: TB-sized databases
Previous:From: Andrej Ricnik-BayDate: 2008-03-17 22:06:50
Subject: Re: performance tools

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