| 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: | Whole Thread | Raw Message | 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 |