On 2026-Feb-27, David Rowley wrote: > > The 'attnullability' thing stands out. It probably doesn't make much of > > a difference -- considering that it's down to 8 bytes already and I > > doubt anything will change if it's instead 6 -- but given these > > definitions > > We could get it to 6 bytes. [...]
> If I make the CompactAttribute 6 bytes, I see gcc producing two LEA > instructions instead of one: [...] > I expect that the extra address calculation costs plus the extra > bitwise-AND for checking attbyval will cost more than it will save. Ah, that makes sense. Interesting, thanks for explaining. > > 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. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
