Hi > How about this -- if you feel strong about this patch series, maybe > let's pick up a single feature out of those you want to propose, isolate > any refactoring needed explicitely to support it and go with the feature > as a motivation? I'm not talking about the original patch set from the > first message in this thread, but something much smaller and digestible.
I agree with Dmitry's suggestion to pick one feature and limit the refactoring to what is needed to support it. Previously I suggested focusing on code movement, but a concrete use case would help us judge the module boundaries and the scope of the changes. > Alternatively, since we are talking about simple reorganization, maybe > it shouldn't even start with patches? Maybe a table (CSV?) of what > functions to move where, and/or some text based diagram format like > mermaid to visualize the architecture/structure you want to get, if > you want to talk about the long term vision? I also think Zsolt's suggestion of using a table or diagram could help us discuss the proposed structure for that feature before working on the patches. IIUC, the earlier proposal [1] includes extracting shared implementations of distribution generators, permutation functions, and hash functions, and exposing them through a server-side extension. For example, how about starting with the distribution generators and limiting the scope to those? Generating skewed test data in SQL using pgbench’s distribution algorithms would give us a concrete reason for that refactoring. [1] https://www.postgresql.org/message-id/CAMT0RQQ1Y47QSeLkVfF5SfanJMpDU%2B2QBPjDLXaBkB7PMVQXOQ%40mail.gmail.com Koshi Shibagaki FUJITSU LIMITED https://www.fujitsu.com/
