aboutsummaryrefslogtreecommitdiff
path: root/src/backend/jit/llvm/llvmjit_inline.cpp
diff options
context:
space:
mode:
authorPeter Geoghegan <pg@bowt.ie>2021-09-21 18:57:32 -0700
committerPeter Geoghegan <pg@bowt.ie>2021-09-21 18:57:32 -0700
commitdd94c2852e6e3a246b9fd64bf2d9c7fc01020905 (patch)
treeb30722ab0e1bf1d9a4e66b6481a27016ca24712c /src/backend/jit/llvm/llvmjit_inline.cpp
parent1a9d802828110c87a207785aaf6b00d8917a86ad (diff)
downloadpostgresql-dd94c2852e6e3a246b9fd64bf2d9c7fc01020905.tar.gz
postgresql-dd94c2852e6e3a246b9fd64bf2d9c7fc01020905.zip
Fix "single value strategy" index deletion issue.
It is not appropriate for deduplication to apply single value strategy when triggered by a bottom-up index deletion pass. This wastes cycles because later bottom-up deletion passes will overinterpret older duplicate tuples that deduplication actually just skipped over "by design". It also makes bottom-up deletion much less effective for low cardinality indexes that happen to cross a meaningless "index has single key value per leaf page" threshold. To fix, slightly narrow the conditions under which deduplication's single value strategy is considered. We already avoided the strategy for a unique index, since our high level goal must just be to buy time for VACUUM to run (not to buy space). We'll now also avoid it when we just had a bottom-up pass that reported failure. The two cases share the same high level goal, and already overlapped significantly, so this approach is quite natural. Oversight in commit d168b666, which added bottom-up index deletion. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.com Backpatch: 14-, where bottom-up deletion was introduced.
Diffstat (limited to 'src/backend/jit/llvm/llvmjit_inline.cpp')
0 files changed, 0 insertions, 0 deletions