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

From wieck@debis.com (Jan Wieck)
Subject Re: [SQL] Good Optimization
Date
Msg-id m112A6U-0003ktC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [SQL] Good Optimization  (Patrik Kudo <kudo@partitur.se>)
Responses Re: [SQL] Good Optimization
Re: [SQL] Good Optimization
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?

    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@debis.com (Jan Wieck) #

pgsql-sql by date:

Previous
From: Eric BASIER
Date:
Subject: concatenation varchar and float
Next
From: Patrik Kudo
Date:
Subject: Re: [SQL] Good Optimization