Re: plpgsql function startup-time improvements

Hi 2018-01-25 0:16 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > please, can you rebase all three patches necessary for patching? > > Done. These now need to be applied over > https://www.postgresql.org/message-id/833.1516834...@sss.pgh.pa.us

Re: plpgsql function startup-time improvements

Pavel Stehule writes: > please, can you rebase all three patches necessary for patching? Done. These now need to be applied over https://www.postgresql.org/message-id/833.1516834...@sss.pgh.pa.us regards, tom lane diff --git

Re: plpgsql function startup-time improvements

Moin, On Thu, December 28, 2017 5:43 pm, Tom Lane wrote: > "Tels" writes: >> On Wed, December 27, 2017 3:38 pm, Tom Lane wrote: >>> Also, I changed PLpgSQL_var.isconst and PLpgSQL_var.notnull from "int" >>> to "bool", which is what they should have been all along,

Re: plpgsql function startup-time improvements

"Tels" writes: > On Wed, December 27, 2017 3:38 pm, Tom Lane wrote: >> Also, I changed PLpgSQL_var.isconst and PLpgSQL_var.notnull from "int" >> to "bool", which is what they should have been all along, and relocated >> them in the PLpgSQL_var struct. > With a

Re: plpgsql function startup-time improvements

Hello Tom, On Wed, December 27, 2017 3:38 pm, Tom Lane wrote: > Attached are patches for two performance-improvement ideas that came > to me while working on [snip] > > Also, I changed PLpgSQL_var.isconst and PLpgSQL_var.notnull from "int" > to "bool", which is what they should have been all

Re: plpgsql function startup-time improvements

On 12/27/17 15:38, Tom Lane wrote: > It seems possible that the "promise" technique could be useful for > other plpgsql special variables in future. I thought briefly about > applying it to triggers' NEW and OLD arguments, but desisted because > (a) it's only a win if triggers will commonly not

plpgsql function startup-time improvements

Attached are patches for two performance-improvement ideas that came to me while working on https://www.postgresql.org/message-id/8962.1514399...@sss.pgh.pa.us The three patches are logically independent and could be committed in any order. But they touch some overlapping code, so as presented,