On Sun, Apr 5, 2026 at 6:46 PM Tomas Vondra <[email protected]> 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
