RE: [SQL] Good Optimization

From: "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>
To: "'pgsql-sql(at)postgresql(dot)org'" <pgsql-sql(at)postgresql(dot)org>
Subject: RE: [SQL] Good Optimization
Date: 1999-07-09 09:59:34
Message-ID: 1BF7C7482189D211B03F00805F8527F70ED012@S-NATH-EXCH2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-sql by date

  From Date Subject
Next Message Ansley, Michael 1999-07-09 10:15:09 Good Optimization
Previous Message Roland_DUBOULOZ 1999-07-09 09:25:13 Bad date representation