diff options
author | David Rowley <drowley@postgresql.org> | 2023-03-20 16:26:04 +1300 |
---|---|---|
committer | David Rowley <drowley@postgresql.org> | 2023-03-20 16:26:04 +1300 |
commit | 785f7095767e148995d276fe52f6b1e1af76e726 (patch) | |
tree | 919b733a64eb532c699ac53fbe78828f764ae643 /src/backend/access/gist/gist.c | |
parent | 579ee5df14dfcf5213e502bb096121d2249167c2 (diff) | |
download | postgresql-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