On Sun, Apr 5, 2026 at 6:46 PM Tomas Vondra <tomas@vondra.me> wrote:
>
> On 4/6/26 00:18, Melanie Plageman wrote:
>
> > While this is the opposite direction of what I suggested to fix BHS in
> > [1], what if we allocated the instrumentation and parallel-aware state
> > separately and accessed them with their own keys? It's a little janky
> > because what key could we use besides the plan_node_id, but if we add
> > a key-sized offset to the plan node id, we can functionally have two
> > separate keys.
>
> Presumably, we'd only do this in master? It seems way too invasive to
> backpatch (and for index scans it'd even be an ABI break, so we can't do
> that). Moreover, for index scans it's not even a bug, and it does not
> seem great to do it one way for BHS and a completely different way in
> index scans.
>
> So we'd either not fix BHS in backbranches, or do it the "ugly" way.
I think we could backpatch the BHS patch I posted in the other thread
that always allocated pstate. It's a very small diff and seems quite
low risk to me. Though that struct changed a lot in 17 I think
(courtesy of me), so backpatching might be a little bit of a headache
in earlier versions.
> > If we don't do the above, then I think your current approach is the
> > only other realistic option. We can't do what I suggested for BHS in
> > [1] and always allocate the parallel-aware state because that state is
> > much larger for sequential scans and TID range scans.
>
> Yeah. I was wondering about these costs when you proposed to allocate
> the BHS parallel state always. I concluded it does not matter for BHS,
> but for scans with larger states it might be different.
Yea, I think ParallelBitmapHeapState is like 48 bytes or something
- Melanie
