Re: More speedups for tuple deformation

From: Andres Freund <andres(at)anarazel(dot)de>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: More speedups for tuple deformation
Date: 2026-02-26 15:08:34
Message-ID: 5vkfd6d657umlibsps4v5un55vsttrmc4yzslzx7ec3mcbyvei@bbncafbqvtjp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-02-26 15:14:37 Re: pgstat include expansion
Previous Message Álvaro Herrera 2026-02-26 15:01:26 Re: More speedups for tuple deformation