Re: Improving executor performance
От | Andres Freund |
---|---|
Тема | Re: Improving executor performance |
Дата | |
Msg-id | 20161108112053.jx7eilyhqdcprfrx@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Improving executor performance (Doug Doole <dougdoole@gmail.com>) |
Список | pgsql-hackers |
Hi, On 2016-11-04 15:25:58 -0700, Doug Doole wrote: > On 07/13/2016 06:18 PM, Andres Freund wrote: > > Attached (in patch 0003) is a proof-of-concept implementing an > > expression evalution framework that doesn't use recursion. Instead > > ExecInitExpr2 computes a number of 'steps' necessary to compute an > > expression. These steps are stored in a linear array, and executed one > > after another (save boolean expressions, which can jump to later steps). > > E.g. to compute colname = 1 the steps are 1) fetch var, 2) evaluate > > const, 3) call function. > > We've been having trouble with the performance of simple expressions in > PLpgSQL so I started playing with this patch. (No sense re-inventing the > wheel after all.) It was straightforward to extend to simple expressions and > showed an immediate improvement (~10% faster on a simple test). That's cool. > Running in our full environment highlighted a few areas that I think > are worth more investigation. There indeed should be many of those. > However, before I tackle that, is the posted proof-of-concept still the > latest and greatest? If not, any chance of getting the latest? It's definitely *not* the latest and greatest. My latest version actually passes all regression tests, and has a few additional expression types handled natively (NULL tests, CASE IIRC), and more than few bugs fixed. I'm away at the moment, but I plan to post a new version end of this or beginning of next week. > Going forward, I'd like to collaborate on our efforts if you're interested. That sounds good! Regards, Andres
В списке pgsql-hackers по дате отправления: