| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Use BumpContext contexts for TupleHashTables' tablecxt |
| Date: | 2025-10-27 03:55:38 |
| Message-ID: | 2314283.1761537338@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>> On Mon, 27 Oct 2025 at 09:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I looked at the callers of BuildTupleHashTable, and realized that
>>> (a) every one of them can use a BumpContext for the "tablecxt",
>>> and (b) Jeff Davis already noticed that for nodeAgg.c, in commit
>>> cc721c459. So we have precedent for the idea working. Here's
>>> a fleshed-out patch to fix the remaining callers.
> I just did a quick test of this with the best-case I could imagine,
> where all rows are filtered, thus reducing the additional overhead of
> going into other nodes. Patched came out about 9% faster than master
> (without MEMORY_CONTEXT_CHECKING).
Hmm, I wasn't really expecting any direct time saving; the point
was about cutting memory consumption. So Chao Li's nearby results
are in line with mine.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2025-10-27 04:05:49 | RE: issue with synchronized_standby_slots |
| Previous Message | David Rowley | 2025-10-27 03:50:33 | Re: Enhance statistics reset functions to return reset timestamp |