On Thu, Sep 3, 2026 at 4:09 PM Michael Paquier <[email protected]> wrote: > On Thu, Sep 03, 2026 at 02:35:53PM +0900, Etsuro Fujita wrote: > > How about setting those parameters as well, as we did before, because > > we might use them in *_statistics_update_internal() in the future, as > > I said upthread? IOW: I still don't think it's a good idea to > > complicate the core code just for those parameters in the FDW case. I > > think that that would just make the version diff large and > > back-patching hard. > > Hmm. I'm not sure that this is correct with a v19 in mind.
> Even with my disagreements, it is pretty clear that you do not like > these improvements, so I'll revert the refactoring piece. I am not > planning to argue much for the FDW part (honestly I don't like the way > this has been coded, and I regret not having spent a couple of cycles > looking at what was happening, but I did not commit that). For the > stats part, though, I am going to be on standby and more careful for > any changes suggested. Thanks for the consideration! I'm open to comments/suggestions, but I'm not 100% sure that the changes in the FDW part are really improvements. > Another part that I do not find acceptable is the "unused" arguments > based on the StatsInfo. That's overlapping the import and restore > bits, IMO. That part alone makes the 0001 proposed upthread a no-go > here. I like the 0001 patch (except the handling of the "unused" arguments). Code changes made by it is really minimized, so it won't make back-patching hard, which is good. Thanks for working on the patch! As for the handling, I think we should just set the arguments as well, as we did before, for the possible use in *_statistics_update_internal() in the future, as I said above. I think that that is more future-proof. Best regards, Etsuro Fujita
