Received: from wolff.to (wolff.to [66.92.219.49]) by postgresql.org (Postfix) with SMTP id CD734474E71 for ; Tue, 16 Jul 2002 07:40:07 -0400 (EDT) Received: (qmail 29373 invoked by uid 500); 16 Jul 2002 11:45:53 -0000 Date: Tue, 16 Jul 2002 06:45:53 -0500 From: Bruno Wolff III To: Josh Berkus Cc: Stephan Szabo , pgsql-sql@postgresql.org Subject: Re: Indexing UNIONs Message-ID: <20020716114553.GB29323@wolff.to> Mail-Followup-To: Josh Berkus , Stephan Szabo , pgsql-sql@postgresql.org References: <20020715130911.V41271-100000@megazone23.bigpanda.com> <200207151731.24567.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207151731.24567.josh@agliodbs.com> User-Agent: Mutt/1.3.25i X-Archive-Number: 200207/238 X-Sequence-Number: 8616 On Mon, Jul 15, 2002 at 17:31:24 -0700, Josh Berkus wrote: > 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 > hold the Unioned data and index that instead? It wouldn't have to be a dummy table. You could have both sets of data in the same table. Since they seem to be related enough that you went to the trouble to give them compatible primary keys this may not be inappropiate (though you must have had some reason for keeping them separate). You can use a flag to indicate what the data type is. If you need fast access to the smaller part of the table, a partial index might work. If the column that didn't apply to the one table is always not null in the other table, you could use is null on that column as your flag.