Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [SQL] cursor and update + view

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: s-fery(at)kkt(dot)sote(dot)hu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [SQL] cursor and update + view
Date: 1998-11-26 03:27:44
Message-ID: 365CCAB0.CE4B0143@krs.ru (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-sql
Jan Wieck wrote:
> 
> > On the other hand, as we talk about query optimization - why
> > rule system should do optimizer' work? Why not just put
> > _any_ VIEW' query into FROM and let optimizer decide
> > could query be rewritten as join or not? Ppl do strange
> > things sometimes -:) Sometimes they use subqueries in
> > WHERE while joins could be used and our optimizer don't
> > try to catch this. I know that Sybase does.
> > And, imho, we should implement this ... sometime -:))
> 
>     Depends on where the optimization is done. If we do it on the
>     parsetree (Query struct), it's the job of  the  rule  system.
>     The optimizer does not have to modify the parsetree. If it is
>     done on the way from the parsetree to the plan, it is the job
>     of the optimizer.
> 
>     If  it  is  possible to do it on the parsetree, I would do it
>     there.

Subquery --> Join transformation/optimization implemented in
rule system will be used for Views only. Being implemented
in optimizer it will be used in all cases.

Vadim

In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 1998-11-26 10:37:28
Subject: Re: [HACKERS] Re: [SQL] cursor and update + view
Previous:From: Vadim MikheevDate: 1998-11-26 03:11:17
Subject: Re: [HACKERS] 6.4.x

pgsql-sql by date

Next:From: Jan WieckDate: 1998-11-26 10:37:28
Subject: Re: [HACKERS] Re: [SQL] cursor and update + view
Previous:From: Tom LaneDate: 1998-11-25 18:05:11
Subject: char type seems the same as char(1)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group