Re: [SQL] Good Optimization
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [SQL] Good Optimization |
Дата | |
Msg-id | m112A6U-0003ktC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [SQL] Good Optimization (Patrik Kudo <kudo@partitur.se>) |
Ответы |
Re: [SQL] Good Optimization
Re: [SQL] Good Optimization |
Список | 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 по дате отправления: