| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | John Naylor <johncnaylorls(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add bump memory context type and use it for tuplesorts |
| Date: | 2024-03-11 23:40:59 |
| Message-ID: | CAApHDvoOcNzDcVtyiggrrg6nt+M4NHwMjzM0k+az8qGFHEcB9Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 12 Mar 2024 at 12:25, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> (b) slab is considerably slower
It would be interesting to modify SlabReset() to, instead of free()ing
the blocks, push the first SLAB_MAXIMUM_EMPTY_BLOCKS of them onto the
emptyblocks list.
That might give us an idea of how much overhead comes from malloc/free.
Having something like this as an option when creating a context might
be a good idea. generation.c now keeps 1 "freeblock" which currently
does not persist during context resets. Some memory context usages
might suit having an option like this. Maybe something like the
executor's per-tuple context, which perhaps (c|sh)ould be a generation
context... However, saying that, I see you measure it to be slightly
slower than aset.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2024-03-11 23:41:38 | Re: Add bump memory context type and use it for tuplesorts |
| Previous Message | Tomas Vondra | 2024-03-11 23:25:01 | Re: Add bump memory context type and use it for tuplesorts |