Re: Add bump memory context type and use it for tuplesorts

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add bump memory context type and use it for tuplesorts
Date: 2024-02-20 09:46:08
Message-ID: CAApHDvovpWiH8ZkaFiGFB6NuWrgicPP=6xAd0YR2Q1NiLct6VQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 26 Jul 2023 at 12:11, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> I think it'd be okay to steal those bits. AFAICT it'd complicate the
> macros in memutils_memorychunk.h a bit, but that doesn't seem like such a
> terrible price to pay to allow us to keep avoiding the glibc bit patterns.

I've not adjusted anything here and I've kept the patch using the
>128KB glibc bit pattern. I think it was a good idea to make our
lives easier if someone came to us with a bug report, but it's not
like the reserved patterns are guaranteed to cover all malloc
implementations. What's there is just to cover the likely candidates.
I'd like to avoid adding any bit shift instructions in the code that
decodes the hdrmask.

> > + if (base->sortopt & TUPLESORT_ALLOWBOUNDED)
> > + tuplen = GetMemoryChunkSpace(tuple);
> > + else
> > + tuplen = MAXALIGN(tuple->t_len);
>
> nitpick: I see this repeated in a few places, and I wonder if it might
> deserve a comment.

I ended up adding a macro and a comment in each location that does this.

> I haven't had a chance to try out your benchmark, but I'm hoping to do so
> in the near future.

Great. It would be good to get a 2nd opinion.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2024-02-20 09:50:48 Re: About a recently-added message
Previous Message vignesh C 2024-02-20 09:44:14 Re: speed up a logical replica setup