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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-11-26 10:37:28 | Re: [HACKERS] Re: [SQL] cursor and update + view |
Previous Message | Vadim Mikheev | 1998-11-26 03:11:17 | Re: [HACKERS] 6.4.x |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-11-26 10:37:28 | Re: [HACKERS] Re: [SQL] cursor and update + view |
Previous Message | Tom Lane | 1998-11-25 18:05:11 | char type seems the same as char(1) |