Re: [PATCH v1 1/1] Add GENERATED ALWAYS AS ROW IDENTITY columns

On Sat, Oct 24, 2026 at 3:02 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Fri, Oct 23, 2026 at 08:39:36PM +0200, Hannu Krosing wrote:
> > On Fri, Oct 23, 2026 at 1:41 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> >> I think you have to stop flooding this list with code that nobody wrote
> >> and nobody will read.
>
> +1.
>
> > 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.
>
> You could send ideas, without patches attached,

That does not work too well, as people often claim it can not be done.
Having a proof of concept demonstrates that it can be done, and that
it has the benefits I claimed.

> or just let them live on a branch somewhere else and post a link to it.

Yup, I figured out this wis actually the way to do it.

It will make the patch evolution less visible here, so at some point
the patches should still go through the list, but that can be later.

> If you just post a
> concept in a few words or a design, an LLM could most likely digest
> your idea and produce code matching with what's been done, these days.

Nah. Any Larger things I have posted here have gone through at least
weeks if not months of development, debugging and tuning.

I probably could send the resulting, quite long, detailed design docs
if you think these could get some traction more easily?

> > Was marking it [PATCH] the main confusing thing, or was there also
> > something else?
>
> Sending a zillion number of AI-generated POC ideas on the lists is not
> a particularly useful thing to do and not a useful thing to load the
> Postgres infrastructure servers with.

I don't think the infrastructure is that bad. But if this distracts
people who are already severely overloaded by AI finding gazillion
bugs in existing code, then I of course should not continue doing it.

> Spoiler: my own impression is that your contents are mostly
> copy-pasted from AI-generated contents, they give zero impression that
> you put efforts in it yourself, and that you just gave orders to an
> LLM to do something.

These things are not at all mutually exclusive. In fact, I have put
many man-months of work into the larger ones. But the work has mainly
been at the architectural level, not low level code.

> I tend to just ignore these as noise; and I'm in
> peace with that depending on the contents posted because it's less
> noise to deal with and I can focus on getting actual quality work
> done. There are exchanges with your ideas where I see that folks
> (senior contributors, committers) clearly raise eyebrows and say that
> they may not be good ideas.

That's why I try to post PoC code. Often the only way to convince
people that something works is to *show* that it works.

Occasionally I have been able to convince them, sometimes I just give
up and keep using the things myself and have a better (more
performant, more stable, les lock-ups, etc) product.

The reason we have Vvacuum now that can clean up dead tuples while
othe long vacuums are running is that there was a 10 year PostgreSQL
anniversary conference in 2006 and there was a hacking session, where
I was able to tell Alvaro to put that in too.
Else the patch was done, had some useful comments from Tom and others
in first month or so and then was used for production at Skype for a
year, and every two months Bruce asked about getting it in, but nobody
really seemed to care. I guess we were the only ones using PostgreSQL
with large production workloads at that time.

And the same thing continues to this day,

I also have some nice ancient hand-crafted, fully artisanal patches
which solve specific cases, and these do not get any attention ether,
fter the initial issues get fixed. Basically people are ok to tell
what is wrong (thank you all, very valuable!), but once the patch has
no obvious flaws, it just lingers there.

1. https://commitfest.postgresql.org/patch/5774/ - "Extend skipping FK
checks on replicas to include ADD FK and TRUNCATE", 1.5 years old

This avoids many hours (on hge tables) of completely unneccesary work
when replica or restore checks foreign key validity between two tables
which were copied out from a valid database.

2. https://commitfest.postgresql.org/patch/6219/ - "pg_dump flag for
dumping tables data in multiple chunks, for huge tables can often give
near-linear speedup when parallelized", 1 year old

This allows speeding up dumping data from a single huge table if you
do have extra CPU, disk and network bandwidth.

And yes, often also the stupid indexed TOAST is involved, but at least
this allows operations to run near disk speed by throwing lots of CPU
at it.

This isn't a trivial speedup, it can reduce a 10-day dump to just a few hours.

I also had a patch that solves it by just dumping TOAST table
separately which makes it all run at good speeds without extra CPU,
but I did not even try to upstream that one knowing how unorthodox
that would be considered. This one btw works well only with the
Indexed TOAST :)

> Overall, it feels to me that you keep
> rejecting these arguments on the ground that your ideas are better.

What other grounds there could be?

> Consensus is a multi-dimensional concept, it is not one-dimensional.

They mostly are *technically* better, but yes, consensus is a tricky
thing and can take a long time to get to.

Interestingly some of them seem to understand much better when talked
to in person.

> What makes me sad is that these MBs worth of patches just act as a way
> to backup your data in everybody's mail boxes, for stuff that I
> suspect few are really interested to look at. Posting ideas in the
> shape of an email is fine, bumping dozens of MBs worth of data that
> only another AI is able to digest is an insane loop to enter. If you
> are not ready to argue over each line of code, perhaps the code is not
> good for posting it yet.

This is more a comment on how PostgreSQL development and code reviews work :)

> After writing that, I'll go back to enjoying my weekend.

Sure, have a nice weekend! :)

And thanks for comments.

----
Hannu