Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.3/8.9.3) with ESMTP id KAA72226
	for <pgsql-sql@postgreSQL.org>; Tue, 1 Jun 1999 10:06:04 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA21257;
	Tue, 1 Jun 1999 10:04:59 -0400 (EDT)
To: Remigiusz Sokolowski <rems@gdansk.sprint.pl>
cc: pgsql-sql@postgreSQL.org
Subject: Re: [SQL] indexes 
In-reply-to: Your message of Tue, 1 Jun 1999 08:41:07 +0200 (MET DST)
	<Pine.GS4.4.02A.9906010826460.18822-100000@netra.gdansk.sprint.pl>
Date: Tue, 01 Jun 1999 10:04:59 -0400
Message-ID: <21255.928245899@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Remigiusz Sokolowski <rems@gdansk.sprint.pl> writes:
> But without Vadim's suggestion I've got still similar results - sometimes
> optimizer has used index on e1 and on b1, sometimes on e1 and e2, but
> never on e1,b1 and e2 at once (note: this was join on ent e1, binds b1 and
> ent e2)

You won't ever see a three-way join in EXPLAIN's output, if that was
what you were looking for.  Postgres always handles joins by combining
two tables, then combining the result with another table, etc.

			regards, tom lane