| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Make tuple deformation faster |
| Date: | 2025-03-05 21:17:25 |
| Message-ID: | lhikcsnicveyuikr6mlp6f5dp3jqpsipqo3r5omz3b3ddxrqtt@2io4oiiufzh6 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-03-05 12:15:57 -0800, Jeff Davis wrote:
> On Wed, 2025-03-05 at 11:33 -0800, James Hunter wrote:
> > For a bitfield, however, the CPU has to read from or write to the
> > byte
> > that contains the bit, but then it also has to mask out the *other*
> > bits in that bitfield. This is a data dependency, so it stalls the
> > CPU
> > pipeline.
>
> Here the bits aren't changing, so we're only talking about mask-and-
> test, right? My intuition is that wouldn't cause much of a problem.
FWIW, I am fairly certain that I looked at this at an earlier state of the
patch, and at least for me the issue wasn't that it was inherently slower to
use the bitmask, but that it was hard to convince the compiler not generate
worse code.
IIRC the compiler generated more complicated address gathering instructions
which are slower on some older microarchitectures, but this is a vague memory.
Greetings,
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2025-03-05 21:21:40 | Re: Remove curl installation from CI images |
| Previous Message | Robert Haas | 2025-03-05 21:13:06 | Re: making EXPLAIN extensible |