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
Thank you
I checked it
1. there are no proble
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 a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgs
Hi
2017-12-27 21:38 GMT+01:00 Tom Lane :
> 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
"Tels" writes:
> On Thu, December 28, 2017 5:43 pm, Tom Lane wrote:
>> Which field order were you checking? Are you accounting for alignment
>> padding?
> ...
> Sounds logical, thanx for the detailed explanation. In my test the first 4
> padding bytes are probably not there, because I probably mi
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, and relocated
>>> them in the PL
"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 short test program printing out the
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 along
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 to
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,
yo
