Re: Improving executor performance
От
Doug Doole
Тема
Re: Improving executor performance
Дата
Msg-id
be2aa0e9-81b9-6510-b2ad-28a21a9580aa@gmail.com
Ответ на
Re: Improving executor performance (Andres Freund)
Список
Дерево обсуждения
Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Andreas Seltenreich <seltenreich@gmx.de>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Andreas Seltenreich <seltenreich@gmx.de>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Andreas Seltenreich <seltenreich@gmx.de>
Re: Improving executor performance Doug Doole <dougdoole@gmail.com>
Re: Improving executor performance Doug Doole <dougdoole@gmail.com>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Peter Geoghegan <pg@heroku.com>
Re: Improving executor performance - tidbitmap Andres Freund <andres@anarazel.de>
Re: Improving executor performance - tidbitmap Robert Haas <robertmhaas@gmail.com>
Re: Improving executor performance - tidbitmap Andres Freund <andres@anarazel.de>
Re: Improving executor performance - tidbitmap Peter Geoghegan <pg@heroku.com>
Re: Improving executor performance - tidbitmap Andres Freund <andres@anarazel.de>
Re: Improving executor performance - tidbitmap Peter Geoghegan <pg@heroku.com>
Re: Improving executor performance Rajeev rastogi <rajeev.rastogi@huawei.com>
Re: Improving executor performance Andres Freund <andres@anarazel.de>
Re: Improving executor performance Craig Ringer <craig@2ndquadrant.com>
Re: Improving executor performance Peter Geoghegan <pg@heroku.com>
Re: Improving executor performance Bruce Momjian <bruce@momjian.us>
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). Running in our full environment highlighted a few areas that I think are worth more investigation. However, before I tackle that, is the posted proof-of-concept still the latest and greatest? If not, any chance of getting the latest? Going forward, I'd like to collaborate on our efforts if you're interested. - Doug Doole Salesforce
В списке pgsql-hackers по дате отправления