aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonfuncs.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2022-09-01 11:08:10 +1200
committerDavid Rowley <drowley@postgresql.org>2022-09-01 11:08:10 +1200
commit1083f94dacde5f5b383ca8e18a85babb5cb5e77f (patch)
tree60f9f7adeeaa214784e380f92c9684a1f316d96c /src/backend/utils/adt/jsonfuncs.c
parent349baa87ae4bf1c65c3ed34073837a71a725b30b (diff)
downloadpostgresql-1083f94dacde5f5b383ca8e18a85babb5cb5e77f.tar.gz
postgresql-1083f94dacde5f5b383ca8e18a85babb5cb5e77f.zip
Be smarter about freeing tuples during tuplesorts
During dumptuples() the call to writetuple() would pfree any non-null tuple. This was quite wasteful as this happens just before we perform a reset of the context which stores all of those tuples. It seems to make sense to do a bit of a code refactor to make this work, so here we just get rid of the writetuple function and adjust the WRITETUP macro to call the state's writetup function. The WRITETUP usage in mergeonerun() always has state->slabAllocatorUsed == true, so writetuple() would never free the tuple or do any memory accounting. The only call path that needs memory accounting done is in dumptuples(), so let's just do it manually there. In passing, let's get rid of the state->memtupcount-- code that counts the memtupcount down to 0 one tuple at a time inside the loop. That seems to be a rather inefficient way to set memtupcount to 0, so let's just zero it after the loop instead. Author: David Rowley Discussion: https://postgr.es/m/CAApHDvqZXoDCyrfCzZJR0-xH+7_q+GgitcQiYXUjRani7h4j8Q@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/jsonfuncs.c')
0 files changed, 0 insertions, 0 deletions