On Thu, Sep 03, 2026 at 01:42:09PM -0500, Nathan Bossart wrote: > On Thu, Sep 03, 2026 at 12:35:26PM +0900, Michael Paquier wrote: >> Hmm. Adding Nathan in CC on this one for comment from the RMT. It's >> rather low priority compared to all the open items I can see listed on >> the wiki, but it's an option I find worth considering by the day. I >> don't want to put more stress than necessary on the RMT regarding this >> thread, though.. > > From later the discussion, it looks like there's nothing that needs RMT > review at the moment. Please let me know if I've got that wrong.
FWIW, the best conclusion that I can offer regarding this thread on my side is that I am pretty unhappy with the decisions taken on REL_19_STABLE on the core backend side regarding the way the stats import code has been plugged, reflecting in the way FDWs need to work with that. It is not entirely the fault of the stats import code, because the stats import code has been trying to work around decisions that have been taken in v18 for the relation and attribute stats. What feels wrong to me is that we are trying to work around these decisions after-the-fact. A more logical flow that I try to follow is first to fix the original underlying issues, even if it means reverting any new code, provide a clean basis, then work on top of the clean basis, and not work *around* them. That pretty much reflects my feeling regarding this thread: 0001 is a reflection of what looks like a workaround (the "unused" bits are one part of that, but not everything I feel rather weird about), and the early choices from v18 reflect into the rest in the code tree in what spreads as unelegant ways. That has a long-term cost I'd like to not underestimate. Using structures and splitting the dependencies between the stats restore and stats import logic as I was proposing was providing a cleaner split, IMO. Even if I agree that it still is a sort of workaround, there is nothing better I can propose as long as we don't have a cleaner basis. I don't think that I would not have done things this way and did not originally commit any of that, so I'm by definition not its owner and we all have our style quirks. In terms of my own qwirks I tend to pick up community-style consistency, not of all us do which is fine by me. So, shrug? ¯\(ツ)/¯ -- Michael
signature.asc
Description: PGP signature
