On Fri, Oct 23, 2026 at 1:41 PM Álvaro Herrera <[email protected]> wrote: > > On 2026-Oct-23, Hannu Krosing wrote: > > > This is something I have been thinking of for some time and here is a > > proof of concept implementation to verify the advantages I have hoped > > it will have. > > I think you have to stop flooding this list with code that nobody wrote > and nobody will read.
This was not meant to be final in any way; it was meant to introduce an *idea* with a PoC implementation for people who want to verify its merits. Was marking it [PATCH] the main confusing thing, or was there also something else? ... > > I want progress here, I really do, but this is not the way. What do you think would be a good way to discuss larger ideas that go beyond bugfixes ? > (*) The latest pgbench post was stuck in the moderator queue because of > the message size. I was looking at it earlier today, thinking ... 3 MB > of code ... should I just reject it? In the end, it's not the > moderator's job to take that kind of shot, so it's now published. Thanks! I expect this to be complete for some time regarding the planned functionality. The thing is actually about 5 or six individual patches that need to be applied one after another, first pure moving code from a single one into into separate files, then more structural refactoring, And only after that come the actual enhancements and new features. I now plan to start discussions about adding a patch linking feature to the commitfest app, so one does not need to post same patches in multiple entries (I found 23 such cases over last few years) > But > you should know better than to post multiple 400kB patches of new > features of unknown quality that have never before even been mentioned > in this list, much less discussed about or agreed, in a "Refactor > pgbench code" subject thread. The first 10 patches are indeed refactoring. And I did not want to open another entry that included all the refactoring, so I explained it in the email and the CF entry ---- Hannu
