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 16:39:20
Message-ID: zoa26kkxbfocpvcgnvyo3jgthlf3ulxnqfirkkrtjawe3rxf7g@dglq4m3fnrpi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-02-26 17:01:57 +0100, Álvaro Herrera wrote:
> On 2026-Feb-26, Andres Freund wrote:
>
> > 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.
>
> Eh, my first suggestion was to start the benchmark suite as a top-level
> thing, so put this module under src/benchmark rather than hide it with
> the bunch of smelly dudes in src/test/modules.

I don't particularly care about whether we put it in src/benchmark or
src/test/modules. I don't love either, so whatever.

But I think it's reasonably important that we don't go for "one extension for
every single C benchmark function", because that'll just make the overhead for
adding another benchmark function too high.

And I think we shouldn't install anything in there by default (like with
src/test/modules), as otherwise we'll have to care about the benchmark module
being perfectly safe, which I don't think we want to.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yura Sokolov 2026-02-26 17:02:38 Re: Fix bug in multixact Oldest*MXactId initialization and access
Previous Message Sami Imseih 2026-02-26 16:34:17 Re: Fix bug in multixact Oldest*MXactId initialization and access