diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-08-17 19:39:35 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-08-17 19:39:35 -0400 |
commit | d3eaab3ef0d552a2f6555b0424a32dc9e77fb17c (patch) | |
tree | da31debffe1b02692ac762b1f15189e845d591b6 /src/backend/executor | |
parent | 47ebbdcee7bc4e8dd1b88750ed778c61c4c5ec1b (diff) | |
download | postgresql-d3eaab3ef0d552a2f6555b0424a32dc9e77fb17c.tar.gz postgresql-d3eaab3ef0d552a2f6555b0424a32dc9e77fb17c.zip |
Fix performance bug from conflict between two previous improvements.
My expanded-objects patch (commit 1dc5ebc9077ab742) included code to make
plpgsql pass expanded-object variables as R/W pointers to certain functions
that are trusted for modifying such variables in-place. However, that
optimization got broken by commit 6c82d8d1fdb1f126, which arranged to share
a single ParamListInfo across most expressions evaluated by a plpgsql
function. We don't want a R/W pointer to be passed to other functions
just because we decided one function was safe! Fortunately, the breakage
was in the other direction, of never passing a R/W pointer at all, because
we'd always have pre-initialized the shared array slot with a R/O pointer.
So it was still functionally correct, but we were back to O(N^2)
performance for repeated use of "a := a || x". To fix, force an unshared
param array to be used when the R/W param optimization is active.
Commit 6c82d8d1fdb1f126 is in HEAD only, so no need for a back-patch.
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions