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 |
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 |