From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use generation context to speed up tuplesorts |
Date: | 2021-08-02 22:59:25 |
Message-ID: | CAApHDvqUY3Nb-Yfcd0A4GRX7ce-YL3rOm4emH-hFwpmmDjVf0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 31 Jul 2021 at 08:38, Andres Freund <andres(at)anarazel(dot)de> wrote:
> There is at least one path using tuplecontext that reaches code that
> could end up freeing memory to a significant enough degree to care about
> generation.c effectively not using that memory:
> tuplesort_putdatum()->datumCopy()->EOH_flatten_into()
> On a quick look I didn't find any expanded record user that frees
> nontrivial amounts of memory, but I didn't look all that carefully.
I guess we could just use a normal context for datum sorts if we
thought that might be a problem.
I'm not too familiar with the expanded object code, but I'm struggling
to imagine why anything would need to do a pfree in there. We just do
EOH_get_flat_size() to determine how big to make the allocation then
allocate some memory for EOH_flatten_into() to use to expand the
object into.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-08-02 23:11:10 | Re: Release 13 of the PostgreSQL BuildFarm client |
Previous Message | Bossart, Nathan | 2021-08-02 22:58:49 | Re: make MaxBackends available in _PG_init |