aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.h
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-03-30 20:01:27 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-03-30 20:01:31 -0400
commit65158f497a7d7523ad438b2034d01a560fafe6bd (patch)
treede4d0b2df57bf93cbd1d26be5a6533cc7fb79a89 /contrib/postgres_fdw/postgres_fdw.h
parent9ee7d533dacf8594057ced2d016250f09056c284 (diff)
downloadpostgresql-65158f497a7d7523ad438b2034d01a560fafe6bd.tar.gz
postgresql-65158f497a7d7523ad438b2034d01a560fafe6bd.zip
Remove small inefficiency in ExecARDeleteTriggers/ExecARUpdateTriggers.
Whilst poking at nodeModifyTable.c, I chanced to notice that while its calls to ExecBR*Triggers and ExecIR*Triggers are protected by tests to see if there are any relevant triggers to fire, its calls to ExecAR*Triggers are not; the latter functions do the equivalent tests themselves. This seems possibly reasonable given the more complex conditions involved, but what's less reasonable is that the ExecAR* functions aren't careful to do no work when there is no work to be done. ExecARInsertTriggers gets this right, but the other two will both force creation of a slot that the query may have no use for. ExecARUpdateTriggers additionally performed a usually-useless ExecClearTuple() on that slot. This is probably all pretty microscopic in real workloads, but a cycle shaved is a cycle earned.
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.h')
0 files changed, 0 insertions, 0 deletions