↑↓ select↵ open⌫ change scopeOpen full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

Wiki / Plan Nodes

Memoize

Caches results from a parameterized child and reuses them when the same parameter values recur.

Reading PG 18·Select a recorded version

Core node tag
T_Memoize
Structured EXPLAIN Node Type
Memoize
Inputs
One parameterized child plan
Output
Cached or newly produced child tuples
Executor initializer
ExecInitMemoize
Memory mechanism
eviction
evidence kind
source and documentation
explain names
Memoize
explain prefixes
Parallel, Async
node tag
T_Memoize
parallel callbacks
ExecMemoizeEstimate, ExecMemoizeInitializeDSM, ExecMemoizeInitializeWorker, ExecMemoizeRetrieveInstrumentation
partial modes
Unknown
runtime verified
false
strategies
Unknown

Definition PG 18

Caches results from a parameterized child and reuses them when the same parameter values recur.

EXPLAIN labels in this source build

Text-format labelStructured node identity
MemoizeMemoize

Compare versions

Complete source facts

memory

{"description":"The Memoize cache evicts least-recently-used entries instead of spilling cached tuples to disk. If a result cannot fit, caching can enter bypass mode for that scan.","evidence":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeMemoize.c","path":"src/backend/executor/nodeMemoize.c","sha256":"1dec8adecc70763c97957ed94510c4734a399223fd2f81f5534a30351c06c5d6","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"}],"mechanism":"eviction","source_notes":["The method of cache we use is a hash table. When the cache fills, we never spill tuples to disk, instead, we choose to evict the least recently used cache entry from the cache. We remember the least recently used entry by always pushing new entries and entries we look for onto the tail of a doubly linked list. This means that older items always bubble to the top of this LRU list.","It's possible when we're filling the cache for a given set of parameters that we're unable to free enough memory to store any more tuples. If this happens then we'll have already evicted all other cache entries. When caching another tuple would cause us to exceed our memory budget, we must free the entry that we're currently populating and move the state machine into MEMO_CACHE_BYPASS_MODE. This means that we'll not attempt to cache any further tuples for this particular scan. We don't have the memory for it. The state machine will be reset again on the next rescan. If the memory requirements to cache the next parameter's tuples are less demanding, then that may allow us to start putting useful entries back into the cache again.","cache_lookup Perform a lookup to see if we've already cached tuples based on the scan's current parameters. If we find an existing entry we move it to the end of the LRU list, set *found to true then return it. If we don't find an entry then we create a new one and add it to the end of the LRU list. We also update cache memory accounting and remove older entries if we go over the memory budget. If we managed to free enough memory we return the new entry, else we return NULL.","If we've gone over our memory budget, then we'll free up some space in the cache."]}

source inventory

{"executor":"src/backend/executor/execProcnode.c","explain":"src/backend/commands/explain.c","implementation":"src/backend/executor/nodeMemoize.c"}

Source references

Full definition and evidence JSON

Definition sources

center · PostgreSQL 18 · 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

Text language: en · 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f