| 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
| 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 |