aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2015-02-16 15:28:40 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2015-02-16 15:28:48 -0500
commit9e3ad1aac52454569393a947c06be0d301749362 (patch)
tree814dd1854d0e1cf1fa40bcc81d80df523204b98d /src/backend/access/gist/gistproc.c
parent2c75531a6cc49a56afbd5619c36b3daccbe243fa (diff)
downloadpostgresql-9e3ad1aac52454569393a947c06be0d301749362.tar.gz
postgresql-9e3ad1aac52454569393a947c06be0d301749362.zip
Use fast path in plpgsql's RETURN/RETURN NEXT in more cases.
exec_stmt_return() and exec_stmt_return_next() have fast-path code for handling a simple variable reference (i.e. "return var") without going through the full expression evaluation machinery. For some reason, pl_gram.y was under the impression that this fast path only applied for record/row variables; but in reality code for handling regular scalar variables has been there all along. Adjusting the logic to allow that code to be used actually results in a net savings of code in pl_gram.y (by eliminating some redundancy), and it buys a measurable though not very impressive amount of speedup. Noted while fooling with my expanded-array patch, wherein this makes a much bigger difference because it enables returning an expanded array variable without an extra flattening step. But AFAICS this is a win regardless, so commit it separately.
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions