pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: pgsql-performance@postgreSQL.org
Subject: Re: TB-sized databases
Date: Thu, 06 Dec 2007 23:14:10 -0500
Message-ID: <10359.1197000850@sss.pgh.pa.us> (raw)
In-Reply-To: <4758C425.3080105@cheapcomplexdevices.com>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
	<13851.1196351131@sss.pgh.pa.us>
	<1196352866.4246.1304.camel@ebony.site>
	<200712051507.22745.xzilla@users.sourceforge.net>
	<1196933896.4255.340.camel@ebony.site>
	<20071206154212.GP5294@mathom.us>
	<15753.1196957598@sss.pgh.pa.us>
	<4758A1B8.20501@cheapcomplexdevices.com>
	<4758C425.3080105@cheapcomplexdevices.com>

Ron Mayer <rm_pg@cheapcomplexdevices.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



view thread (61+ messages)  latest in thread

Message-ID: <10359.1197000850@sss.pgh.pa.us>
Permalink:  ../10359.1197000850@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10359.1197000850@sss.pgh.pa.us

 · 

reply
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: tgl@sss.pgh.pa.us, rm_pg@cheapcomplexdevices.com
  Subject: Re: TB-sized databases
  In-Reply-To: <10359.1197000850@sss.pgh.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