Re: Add bump memory context type and use it for tuplesorts - Mailing list pgsql-hackers

From David Rowley
Subject Re: Add bump memory context type and use it for tuplesorts
Date
Msg-id CAApHDvovpWiH8ZkaFiGFB6NuWrgicPP=6xAd0YR2Q1NiLct6VQ@mail.gmail.com
Whole thread Raw
In response to Re: Add bump memory context type and use it for tuplesorts  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Wed, 26 Jul 2023 at 12:11, Nathan Bossart <nathandbossart@gmail.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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: speed up a logical replica setup
Next
From: shveta malik
Date:
Subject: Re: About a recently-added message