aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistutil.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-02-11 12:34:59 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2025-02-11 12:34:59 -0500
commit6c7251db0ce12a83dd03c840e7d0ff7516b27229 (patch)
treee2b16b70d239b580f8ffb66ad50080ac0134f918 /src/backend/access/gist/gistutil.c
parent36fb9ef269a092a1203c9482bdf9b3e963728fd9 (diff)
downloadpostgresql-6c7251db0ce12a83dd03c840e7d0ff7516b27229.tar.gz
postgresql-6c7251db0ce12a83dd03c840e7d0ff7516b27229.zip
Implement new optimization rule for updates of expanded variables.
If a read/write expanded variable is declared locally to the assignment statement that is updating it, and it is referenced exactly once in the assignment RHS, then we can optimize the operation as a direct update of the expanded value, whether or not the function(s) operating on it can be trusted not to modify the value before throwing an error. This works because if an error does get thrown, we no longer care what value the variable has. In cases where that doesn't work, fall back to the previous rule that checks for safety of the top-level function. In any case, postpone determination of whether these optimizations are feasible until we are executing a Param referencing the target variable and that variable holds a R/W expanded object. While the previous incarnation of exec_check_rw_parameter was pretty cheap, this is a bit less so, and our plan to invoke support functions will make it even less so. So avoiding the check for variables where it couldn't be useful should be a win. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com> Discussion: https://postgr.es/m/CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistutil.c')
0 files changed, 0 insertions, 0 deletions