RE: [SQL] Good Optimization - Mailing list pgsql-sql

From Ansley, Michael
Subject RE: [SQL] Good Optimization
Date
Msg-id 1BF7C7482189D211B03F00805F8527F70ED012@S-NATH-EXCH2
Whole thread Raw
List pgsql-sql
> >
> > Bruce Momjian wrote:
> > >=20
> > > Added to TODO:
> > >=20
> > >         * In WHERE x=3D3 AND x=3Dy, add y=3D3
> >
> > I don't know if I'm way off, but wouldn't removing "x=3Dy" improve
> > performance further?
> 
<snip some example stuff>
> 
>     IMHO we're improving optimization more and more on  the  cost
>     of  query  parse/rewrite/optimize/plan time. Thus performance
>     of statements that EXECUTE fast slows  down  more  and  more.
>     Isn't   it   time   to   think   about  some  (maybe  shared)
>     "parsetree->plan" cache that provides ready to use  plans  if
>     only Const values have changed?

Isn't this what stored procs are supposed to be?  If a stored proc is
defined
with parameters, then the query plan is saved, and the execution of the
statement
is saved the effort of having to recompile the plan.  In fact, I think that
SQL 
Server, and possibly Oracle as well, store the plan for any query sent, and
then 
drop it when the connection is terminated.  Perhaps this is something to
think 
about.

MikeA



pgsql-sql by date:

Previous
From: Roland_DUBOULOZ
Date:
Subject: Bad date representation
Next
From: "Ansley, Michael"
Date:
Subject: Good Optimization