diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-07-25 14:02:27 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-07-25 14:02:27 -0400 |
| commit | b154ee63bb659ce280d486db6bbbe77ddec105c5 (patch) | |
| tree | 666939cf45003f052b415ca6526bea56a174a439 /src/backend/optimizer/prep/prepunion.c | |
| parent | 3d0a4636aa4c976e971c05c77e162fc70c61f40b (diff) | |
| download | postgresql-b154ee63bb659ce280d486db6bbbe77ddec105c5.tar.gz postgresql-b154ee63bb659ce280d486db6bbbe77ddec105c5.zip | |
Get rid of artificial restriction on hash table sizes on Windows.
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
Diffstat (limited to 'src/backend/optimizer/prep/prepunion.c')
| -rw-r--r-- | src/backend/optimizer/prep/prepunion.c | 8 |
1 files changed, 3 insertions, 5 deletions
diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c index 037dfaacfd4..e9256a2d4d2 100644 --- a/src/backend/optimizer/prep/prepunion.c +++ b/src/backend/optimizer/prep/prepunion.c @@ -1019,7 +1019,7 @@ choose_hashed_setop(PlannerInfo *root, List *groupClauses, const char *construct) { int numGroupCols = list_length(groupClauses); - int hash_mem = get_hash_mem(); + Size hash_mem_limit = get_hash_memory_limit(); bool can_sort; bool can_hash; Size hashentrysize; @@ -1055,13 +1055,11 @@ choose_hashed_setop(PlannerInfo *root, List *groupClauses, */ hashentrysize = MAXALIGN(input_path->pathtarget->width) + MAXALIGN(SizeofMinimalTupleHeader); - if (hashentrysize * dNumGroups > hash_mem * 1024L) + if (hashentrysize * dNumGroups > hash_mem_limit) return false; /* - * See if the estimated cost is no more than doing it the other way. We - * deliberately give the hash case more memory when hash_mem exceeds - * standard work mem (i.e. when hash_mem_multiplier exceeds 1.0). + * See if the estimated cost is no more than doing it the other way. * * We need to consider input_plan + hashagg versus input_plan + sort + * group. Note that the actual result plan might involve a SetOp or |