Re: [HACKERS] Faster methods for getting SPI results (460%improvement)
| От | Jim Nasby |
|---|---|
| Тема | Re: [HACKERS] Faster methods for getting SPI results (460%improvement) |
| Дата | |
| Msg-id | 53431419-e6fe-ea72-b49b-64f332d79de5@nasby.net обсуждение |
| Ответ на | Re: [HACKERS] Faster methods for getting SPI results (460%improvement) (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: [HACKERS] Faster methods for getting SPI results (460%improvement)
|
| Список | pgsql-hackers |
On 4/6/17 9:04 AM, Peter Eisentraut wrote: > On 4/6/17 03:50, Craig Ringer wrote: >> But otherwise, pending docs changes, I think it's ready for committer. > > My opinion is still that this is ultimately the wrong approach. The > right fix for performance issues in PL/Python is to change PL/Python not > to materialize the list of tuples. Now with this change we would be > moving from two result materializations to one, but I think we are > keeping the wrong one. That's an option for future improvement, but I see no way to accomplish that without completely breaking plpy. I think the best way to handle this would be to allow plpython functions to define their own callback function, which would be handed a python tuple that was translated from the SPI result tuple. How best to do that without breaking plpy will require some thought though. In the meantime, I don't think a 27% performance gain is anything to sneeze at, and the SPI changes would be directly usable by pl/r and pl/tcl. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: