public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Álvaro Herrera <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Zsolt Parragi <[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 10:08:34 -0500
Message-ID: <5vkfd6d657umlibsps4v5un55vsttrmc4yzslzx7ec3mcbyvei@bbncafbqvtjp> (raw)
In-Reply-To: <[email protected]>
References: <CAApHDvpBuTZLOQLfDETa9U-je2scAe3_BNXZScwr3hLPc6Hf3g@mail.gmail.com>
	<[email protected]>

Hi,

On 2026-02-26 16:01:26 +0100, Álvaro Herrera wrote:
> On 2026-Feb-27, David Rowley wrote:
> > > 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.

I don't get this. We'll approximately never have a full suite of benchmark
tools that make sense to integrate at once. The reason we're here is because
over and over we've not actually merged quite useful tools, making do with
benchmarking-by-proxy and one off tools.  This seems like a recipe for never
getting anywhere better.

Greetings,

Andres Freund

view thread (4+ messages)

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: <5vkfd6d657umlibsps4v5un55vsttrmc4yzslzx7ec3mcbyvei@bbncafbqvtjp>

* 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