Re: Optimising "full outer join where" for muti-row to multi-column view

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Optimising "full outer join where" for muti-row to multi-column view
Date: 2006-12-28 22:03:29
Message-ID: 20061228220329.GA9484@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Dec 28, 2006 at 08:29:56PM +0000, Phil Endecott wrote:
> To try and avoid this, I tried using a full outer join in the view
> definition. In this case the row would always be present in the view,
> even if the data for the other columns were not present. I hoped that
> the query would then be optimised to look up only the orientation
> information:

<snip>

You really want a left outer join, not a full outer (is the full outer
join even producing the answer you expect?). A full outer join can
never be optimised away.

That said, I don't know if the logic exists to optimise away a left
join either. It would only be possible if the join were on the primary,
thus you could be assured of exactly one row.

The only other alternative would be to make each column a subselect
instead. If you don't take that column as output, maybe it optimises
the subquery out entirely?

Like so:

create view view photo_info_v as
select photo_id,
(select orientation from e2 where e2.tag='Orientation' and e2.photo_id = e1.photo_id),
etc

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrus 2006-12-29 00:17:38 Why ContinueUpdateOnError is not implemented in npgsql
Previous Message Phil Endecott 2006-12-28 20:29:56 Optimising "full outer join where" for muti-row to multi-column view