From 6bd4b59a9f3feadddd9d9ddb748e2dbcf5cb40e1 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Wed, 28 Oct 2026 11:42:58 +1300 Subject: [PATCH] Fix broken indentation caused by 34d52e6d3 Per buildfarm member koel Backpatch to 19 to avoid unnecessary variations. Backpatch-through: 19 --- src/backend/executor/execGrouping.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/backend/executor/execGrouping.c b/src/backend/executor/execGrouping.c index 84c66733004..f105fb244f4 100644 --- a/src/backend/executor/execGrouping.c +++ b/src/backend/executor/execGrouping.c @@ -206,16 +206,16 @@ BuildTupleHashTable(PlanState *parent, * clamp the given nelements to fit in that. We'd also better do * something sane when faced with a zero or NaN estimate. There are * various reasons why the planner might not be able to provide a good - * estimate here; for example, recursive CTEs don't base their estimate - * on anything reliable and can yield some rather large estimates. Here - * we cap nbuckets to hash_mem to help prevent insane memory allocations. - * The hash table can still grow when the bucket count is insufficient. - * That will make the query a little slower, but that's better than - * outright failing due to OOM if we were to request an insane bucket - * count. Queries being slightly slower with smaller work_mem values is - * also aligned to user expectations. We purposefully don't include the - * tuple width in this calculation, as that would make the cap depend on - * planner estimates for the tuple width, which could also be unreliable. + * estimate here; for example, recursive CTEs don't base their estimate on + * anything reliable and can yield some rather large estimates. Here we + * cap nbuckets to hash_mem to help prevent insane memory allocations. The + * hash table can still grow when the bucket count is insufficient. That + * will make the query a little slower, but that's better than outright + * failing due to OOM if we were to request an insane bucket count. + * Queries being slightly slower with smaller work_mem values is also + * aligned to user expectations. We purposefully don't include the tuple + * width in this calculation, as that would make the cap depend on planner + * estimates for the tuple width, which could also be unreliable. */ if (isnan(nelements) || nelements <= 0) nbuckets = 1;