mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-10 09:17:39 +08:00
af38498d4c
... as well as its implementation from backend/access/hash/hashfunc.c to backend/utils/hash/hashfn.c. access/hash is the place for the hash index AM, not really appropriate for generic facilities, which is what hash_any is; having things the old way meant that anything using hash_any had to include the AM's include file, pointlessly polluting its namespace with unrelated, unnecessary cruft. Also move the HTEqual strategy number to access/stratnum.h from access/hash.h. To avoid breaking third-party extension code, add an #include "utils/hashutils.h" to access/hash.h. (An easily removed line by committers who enjoy their asbestos suits to protect them from angry extension authors.) Discussion: https://postgr.es/m/201901251935.ser5e4h6djt2@alvherre.pgsql
This directory contains a general purpose data structures, for use anywhere in the backend: binaryheap.c - a binary heap bipartite_match.c - Hopcroft-Karp maximum cardinality algorithm for bipartite graphs bloomfilter.c - probabilistic, space-efficient set membership testing dshash.c - concurrent hash tables backed by dynamic shared memory areas hyperloglog.c - a streaming cardinality estimator ilist.c - single and double-linked lists knapsack.c - knapsack problem solver pairingheap.c - a pairing heap rbtree.c - a red-black tree stringinfo.c - an extensible string type Aside from the inherent characteristics of the data structures, there are a few practical differences between the binary heap and the pairing heap. The binary heap is fully allocated at creation, and cannot be expanded beyond the allocated size. The pairing heap on the other hand has no inherent maximum size, but the caller needs to allocate each element being stored in the heap, while the binary heap works with plain Datums or pointers. The linked-lists in ilist.c can be embedded directly into other structs, as opposed to the List interface in nodes/pg_list.h.