| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Decoupling our alignment assumptions about int64 and double |
| Date: | 2026-02-01 18:20:27 |
| Message-ID: | 350846.1769970027@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Here's a v2 responding to your suggestions. 0001 refactors
> att_align_nominal(), and then 0002 is nearly the same as the
> prior patch except for rebasing over that change.
I did some simple benchmarking and convinced myself that v2-0001
is a measurable win performance-wise even as things stand.
This test case spends nearly all its time in ExecEvalScalarArrayOp,
which has one of the loops improved by v2-0001:
\timing on
do $$
declare a int8[]; i int8 := 1; b bool;
begin
while i < 10000 loop
a[i] := i;
i := i+1;
end loop;
for j in 1..10 loop
for k in 1..10000 loop
b := (k = any(a));
end loop;
end loop;
end $$;
I see about 10% improvement in runtime with 0001 compared to HEAD.
So I'm inclined to go ahead and push that patch, and then return
to considering what we're going to do about int8 vs. double
alignment.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mihail Nikalayeu | 2026-02-01 19:46:31 | Re: Adding REPACK [concurrently] |
| Previous Message | Marcos Pegoraro | 2026-02-01 17:09:16 | Re: Document NULL |