Re: Exploring pass-by-value for small Bitmapset sets

On Tue, 3 Mar 2026 at 03:55, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> Hi,
>
> I played around with the idea of supporting "immediate" Bitmapset
> values that skip allocation and pointer chasing overheads and live in
> registers, as long as they fit. Prototype-grade patch attached.
>[...]
> I'm interested to hear whether people think this sort of thing is
> worth pursuing, how much of a problem Bitmapset manipulation really
> is, whether it's worth hacking on the Node system to achieve that, etc
> etc.

I'd love this, if only because it'll allow us to avoid memory
allocations in long-lived cache contexts. Of course, David's point
about performance stands, but if we don't lose on it I think this will
be a nice improvement in memory usage.

As example, the RelationData struct has 5 bitmapset fields for
table-like relations, and avoiding allocations in the common case of
tables with <<64 or <<32 attributes would likely be a nice saving.
Generally, at least 3 of those bitmaps are populated (key-, pk-, and
hotblockingattr), so avoiding palloc'd memory would save >=72B of
allocations per relcache table; which is ~14% of the current size of
RelationData. That's quite good.

Where do you think this needs hacking on the Node system? AFAIK, all
Bitmapset support functions already are custom, so IIUC nothing needs
to be done for gen_node_support.pl. And I've not noticed any
bitmapsets that are stored in a Node field anywhere; with all of
copy/equal/out/jumble/read*funcs calling directly into the specialized
implementations rather than dispatching through
_*Node()->_*Bitmapset().

Relatedly: I think we should remove Bitmapset's Node tag (removing it
from the Node types) because it is more and more like a scalar/string
type than a proper participant in the Node infrastructure. We don't
tag all palloc'd types with a NodeTag (by far), so I think the reason
we're keeping the tag around now is now mostly historical. The
incidental places that use the generic node methods on Bitmapsets can
probably be adapted, as I think it's highly unlikely that there are
many places that call into generic Node methods with a known Bitmapset
as input.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)