public inbox for [email protected]  

help / color / mirror / Atom feed

From: Álvaro Herrera <[email protected]>
To: David Rowley <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: John Naylor <[email protected]>
Cc: Chao Li <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: More speedups for tuple deformation
Date: Thu, 26 Feb 2026 16:01:26 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAApHDvpBuTZLOQLfDETa9U-je2scAe3_BNXZScwr3hLPc6Hf3g@mail.gmail.com>

On 2026-Feb-27, David Rowley wrote:

> > The 'attnullability' thing stands out.  It probably doesn't make much of
> > a difference -- considering that it's down to 8 bytes already and I
> > doubt anything will change if it's instead 6 -- but given these
> > definitions
> 
> We could get it to 6 bytes. [...]

> If I make the CompactAttribute 6 bytes, I see gcc producing two LEA
> instructions instead of one: [...]

> I expect that the extra address calculation costs plus the extra
> bitwise-AND for checking attbyval will cost more than it will save.

Ah, that makes sense.  Interesting, thanks for explaining.

> > Regarding deform_bench, I wonder if we shouldn't start a proper
> > benchmarking suite [...]
> 
> Yeah. Andres was talking about this in [1]. I'd originally not planned
> on committing deform_bench at all and only put it in the current
> location in the patch as that seemed like the best location for it
> that we have today.  Andres mentioned just having 1 extension and
> adding functions to it. That seems fine to me. I have some other
> things that could go in there. If it's just one extension, then
> there's likely no need to make a special directory for it. Maybe
> src/test/modules is fine. For now, I don't want to focus too much as
> I'd rather get the deformation speedups ready and in.

Hmm, ok.  I'd rather not get it in the tree at all for now, and see what
else can we get in there later.  Then we might have better ideas of what
to do; if we do get it in src/test/modules now, we might not want to
move it elsewhere later as it might be more painful.  As you say, if
it's just one extension then it doesn't matter much where it is.  But we
might get other ideas that require more than one extension, or more than
one benchmarking suite, and then src/test/modules doesn't sound so great
a location.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: More speedups for tuple deformation
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox