Received: from davinci.ethosmedia.com (davinci.ethosmedia.com [209.10.40.250])
	by postgresql.org (Postfix) with ESMTP id 2739C475858
	for <pgsql-sql@postgresql.org>; Mon, 15 Jul 2002 20:27:40 -0400 (EDT)
Received: from [66.219.92.2] (HELO chocolate-mousse)
	by davinci.ethosmedia.com (CommuniGate Pro SMTP 3.5.9)
	with ESMTP id 1578089; Mon, 15 Jul 2002 17:27:41 -0700
Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Subject: Re: Indexing UNIONs
Date: Mon, 15 Jul 2002 17:31:24 -0700
X-Mailer: KMail [version 1.4]
References: <20020715130911.V41271-100000@megazone23.bigpanda.com>
In-Reply-To: <20020715130911.V41271-100000@megazone23.bigpanda.com>
Cc: pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200207151731.24567.josh@agliodbs.com>
X-Archive-Number: 200207/230
X-Sequence-Number: 8608

Stephan,

> We had a discussion recently on -general about this.  Right now the
> planner won't push the conditions down into the arms of the union because
> noone's been sure under what conditions the optimization is safe.

So, if performance is horrible with the view, I should use a dummy table to=
=20
hold the Unioned data and index that instead?

I can understand the difficultyof optimization.  However, the example I=20
supplied is the simplest of unions, and the two Seq Scans do seem to be=20
proceeding against each table seperately.   I think for very simple Unions=
=20
(i.e. no grouping, no filtering within subqueries, etc.) that index usage=
=20
would be reasonable to implement.

However, I can't program it myself, so I'll have to just stick to whining a=
nd=20
pitiful pleading <blink puppy-dog eyes, sniffle>

--=20
-Josh Berkus
 Aglio Database Solutions
 San Francisco