mirror of
https://github.com/postgres/postgres.git
synced 2026-04-12 04:26:44 -04:00
b154ee63bb
The point of introducing the hash_mem_multiplier GUC was to let users reproduce the old behavior of hash aggregation, i.e. that it could use more than work_mem at need. However, the implementation failed to get the job done on Win64, where work_mem is clamped to 2GB to protect various places that calculate memory sizes using "long int". As written, the same clamp was applied to hash_mem. This resulted in severe performance regressions for queries requiring a bit more than 2GB for hash aggregation, as they now spill to disk and there's no way to stop that. Getting rid of the work_mem restriction seems like a good idea, but it's a big job and could not conceivably be back-patched. However, there's only a fairly small number of places that are concerned with the hash_mem value, and it turns out to be possible to remove the restriction there without too much code churn or any ABI breaks. So, let's do that for now to fix the regression, and leave the larger task for another day. This patch does introduce a bit more infrastructure that should help with the larger task, namely pg_bitutils.h support for working with size_t values. Per gripe from Laurent Hasson. Back-patch to v13 where the behavior change came in. Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com |
||
|---|---|---|
| .. | ||
| appendinfo.c | ||
| clauses.c | ||
| inherit.c | ||
| joininfo.c | ||
| Makefile | ||
| orclauses.c | ||
| paramassign.c | ||
| pathnode.c | ||
| placeholder.c | ||
| plancat.c | ||
| predtest.c | ||
| relnode.c | ||
| restrictinfo.c | ||
| tlist.c | ||
| var.c | ||