From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | kudo(at)partitur(dot)se (Patrik Kudo) |
Cc: | maillist(at)candle(dot)pha(dot)pa(dot)us, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] Good Optimization |
Date: | 1999-07-08 09:04:26 |
Message-ID: | m112A6U-0003ktC@orion.SAPserv.Hamburg.dsh.de |
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?
Maybe in the simple case above. But it will probably change
the result set if someone issues
SELECT a.x, b.y FROM a, b WHERE a.x >= 10
AND a.x <= 19
AND a.x = b.x;
which should then get rewritten into
SELECT a.x, b.y FROM a, b WHERE a.x >= 10
AND a.x <= 19
AND a.x = b.x
AND b.x >= 10
AND b.x <= 19;
This time the "a.x = b.x" is important!
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?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Patrik Kudo | 1999-07-08 09:23:14 | Re: [SQL] Good Optimization |
Previous Message | Eric BASIER | 1999-07-08 08:27:43 | concatenation varchar and float |