aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeProjectSet.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-02-13 19:20:37 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2018-02-13 19:20:37 -0500
commitfd333bc763ea104f2a2c10c6b0061c996d4a2f5a (patch)
treeb0d1d82c19da20d2df880de248ee8be8b732e903 /src/backend/executor/nodeProjectSet.c
parent40301c1c8bcbe92a9ba9bf017da03e83476ae0e5 (diff)
downloadpostgresql-fd333bc763ea104f2a2c10c6b0061c996d4a2f5a.tar.gz
postgresql-fd333bc763ea104f2a2c10c6b0061c996d4a2f5a.zip
Speed up plpgsql trigger startup by introducing "promises".
Over the years we've accreted quite a few special variables that are predefined in plpgsql trigger functions. The cost of initializing these variables to their defined values turns out to be a significant part of the runtime of simple triggers; but, undoubtedly, most real-world triggers never examine the values of most of these variables. To improve matters, invent the notion of a variable that has a "promise" attached to it, specifying which of the predetermined values should be assigned to the variable if anything ever reads it. This eliminates all the unneeded startup overhead, in return for a small penalty on accesses to these variables. Tom Lane, reviewed by Pavel Stehule Discussion: https://postgr.es/m/11986.1514407114@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor/nodeProjectSet.c')
0 files changed, 0 insertions, 0 deletions