aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeProjectSet.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2023-03-22 08:44:54 +1300
committerDavid Rowley <drowley@postgresql.org>2023-03-22 08:44:54 +1300
commitf48b4f892f76ee2b34968013c8ea67b1dfd4fa26 (patch)
tree8e1f3ded6cc905f3920fb867fc48f405f3a5667c /src/backend/executor/nodeProjectSet.c
parentb0d8f2d983cb25d1035fae1cd7de214dd67809b4 (diff)
downloadpostgresql-f48b4f892f76ee2b34968013c8ea67b1dfd4fa26.tar.gz
postgresql-f48b4f892f76ee2b34968013c8ea67b1dfd4fa26.zip
Correct Memoize's estimated cache hit ratio calculation
As demonstrated by David Johnston, the Memoize cache hit ratio calculation wasn't quite correct. This change only affects the estimated hit ratio when the estimated number of entries to cache is estimated not to fit inside the cache. For example, if we expect 2000 distinct cache key values and only expect to be able to cache 1000 of those at once due to memory constraints, with an estimate of 10000 calls, if we could store all entries then the hit ratio should be 80% to account for the first 2000 of the 10000 calls to be a cache miss due to the value not being cached yet. If we can only store 1000 entries for each of the 2000 distinct possible values at once then the 80% should be reduced by half to make the final estimate of 40%. Previously, the calculation would have produced an estimated hit ratio of 30%, which wasn't correct. Apply to master only so as not to destabilize plans in the back branches. Reported-by: David G. Johnston Discussion: https://postgr.es/m/CAKFQuwZEmcNk3YQo2Xj4EDUOdY6qakad31rOD1Vc4q1_s68-Ew@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvrV44LwiF4W_qf_RpbGYWSgp1kF=cZr+kTRRaALUfmXqw@mail.gmail.com
Diffstat (limited to 'src/backend/executor/nodeProjectSet.c')
0 files changed, 0 insertions, 0 deletions