summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gist.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2023-03-20 16:26:04 +1300
committerDavid Rowley <drowley@postgresql.org>2023-03-20 16:26:04 +1300
commit785f7095767e148995d276fe52f6b1e1af76e726 (patch)
tree919b733a64eb532c699ac53fbe78828f764ae643 /src/backend/access/gist/gist.c
parent579ee5df14dfcf5213e502bb096121d2249167c2 (diff)
downloadpostgresql-785f7095767e148995d276fe52f6b1e1af76e726.tar.gz
Have the planner account for the Memoize cache key memory
The Memoize executor node stores the cache key values along with the tuple(s) which were found in the outer node which match each key value, however, when the planner tried to estimate how many entries could be stored in the cache, it didn't take into account that the cache key must also be stored. In many cases, this won't make a large difference as the key is likely small in comparison to the tuple(s) being stored, however, it's not impossible to craft cases where the key could take more memory than the tuple(s) stored for it. Here we adjust the planner so it takes into account the estimated amount of memory to store the cache key. Effectively, this change will reduce the estimated cache hit ratio when it's thought that not all items will fit in the cache, thus Memoize will become more expensive in such cases. The executor already takes into account the memory consumed by the cache key, so here we only need to adjust the planner. Discussion: https://postgr.es/m/CAApHDvqGErGuyBfQvBQrTCHDbzLTqoiW=_G9sOzeFxWEc_7auA@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions