Re: HashAgg degenerate case

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: HashAgg degenerate case
Date: 2024-11-08 04:26:09
Message-ID: 4e9bfa724b301b55a2a242ebebcddea62b2e1292.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, 2024-11-06 at 15:50 +1300, David Rowley wrote:
> I don't think it could be that exactly though as that could lead to
> JIT compilation over and over again from the following chain of
> function calls: build_hash_tables() -> build_hash_table() ->
> BuildTupleHashTableExt() -> ExecBuildGroupingEqual() ->
> ExecReadyExpr() -> jit_compile_expr()

New patch attached. It extends ResetTupleHashTable() so that the caller
can force setting a new nbuckets, which recreates the tuplehash_hash.

agg_refill_hash_table() now uses that to recalculate and set the
nbuckets for the current grouping set's hashtab, and frees the hashtab
for all other grouping sets (it "frees" them by setting to a minimal
size bucket array).

Regards,
Jeff Davis

Attachment Content-Type Size
v2-0001-HashAgg-free-hash-table-memory-each-iteration.patch text/x-patch 5.5 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-11-08 05:10:54 Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Previous Message Tender Wang 2024-11-08 02:26:32 Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length