Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id E507D477008
	for <pgsql-sql@postgresql.org>; Wed, 22 Jan 2003 16:50:50 -0500 (EST)
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
	by postgresql.org (Postfix) with ESMTP id E64F2477007
	for <pgsql-sql@postgresql.org>; Wed, 22 Jan 2003 16:09:13 -0500 (EST)
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
	id D13CED613; Wed, 22 Jan 2003 13:09:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by megazone.bigpanda.com (Postfix) with ESMTP
	id C6EA85C03; Wed, 22 Jan 2003 13:09:14 -0800 (PST)
Date: Wed, 22 Jan 2003 13:09:14 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Tomasz Myrta <jasiek@klaster.net>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: To use a VIEW or not to use a View.....
In-Reply-To: <3E2EE918.30006@klaster.net>
Message-ID: <20030122130604.C1159-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS new-20020517
X-Archive-Number: 200301/345
X-Sequence-Number: 11210


On Wed, 22 Jan 2003, Tomasz Myrta wrote:

> Let's make some test:
>
> First, let's create some simple view with 2 tables join:
> drop view pm;
> create view pm as
>  select
>    id_przystanku,
>    m.nazwa
>  from
>    przystanki p
>    join miasta m using (id_miasta);
>
> explain select * from pm where id_przystanku=1230;
> Nested Loop  (cost=0.00..6.26 rows=1 width=23)
>   ->  Index Scan using przystanki_pkey on przystanki p  (cost=0.00..3.14 rows=1 width=8)
>   ->  Index Scan using miasta_pkey on miasta m  (cost=0.00..3.10 rows=1 width=15)
>
>
> Next, let's try query using this view 2 times with explicit join:
> explain select * from pm a join pm b using(id_przystanku) where id_przystanku=1230;
> Hash Join  (cost=13.00..30.10 rows=1 width=46)
>   ->  Hash Join  (cost=6.74..21.02 rows=374 width=23)
>         ->  Seq Scan on przystanki p  (cost=0.00..7.74 rows=374 width=8)
>         ->  Hash  (cost=5.99..5.99 rows=299 width=15)
>               ->  Seq Scan on miasta m  (cost=0.00..5.99 rows=299 width=15)
>   ->  Hash  (cost=6.26..6.26 rows=1 width=23)
>         ->  Nested Loop  (cost=0.00..6.26 rows=1 width=23)
>               ->  Index Scan using przystanki_pkey on przystanki p  (cost=0.00..3.14 rows=1 width=8)
>               ->  Index Scan using miasta_pkey on miasta m  (cost=0.00..3.10 rows=1 width=15)
>
> And now similiar view, but without nesting views:


> drop view pm2;
> create view pm2 as
>  select
>    id_przystanku,
>    m1.nazwa as nazwa1,
>    m2.nazwa as nazwa2
>  from
>    przystanki p1
>    join miasta m1 using (id_miasta)
>    join przystanki p2 using (id_przystanku)
>    join miasta m2 on (m2.id_miasta=p2.id_miasta);

That's not the same join for optimization purposes
since postgresql treats explicit join syntax as a
constraint on the ordering of joins.

The same join would be something like:

przystanki p1 join miasta m1 using (id_miasta)
join (przystanki p2 join miasta m2 using (id_miasta))
 using (id_przystanku)

minus the fact I think you'd need some explicit naming in
there.