Re: Direct Toast PoC

Hi Michael

You are absolutely right about AI use, and this is also what I
repeatedl;y said at the beginning of the mail - this is an
AI-generated code to verify the concept and approach, not something
that is meant for CODE review.

> I am going to be honest here, but I think beginning a thread this way
> is sloppy. First, the entire email and its contents are entirely
> AI-generated, perhaps you have spent some time double-checking the
> contents of the message but it does not give this impression at all;

I added the parts about why I am sharing this now in this form and
that it confirmed the expected performance improvements.

> at least you are being honest regarding the code by saying that you
> have *not looked at the code at all*. And even if the code is
> generated, looking at the result is the first thing you should try to
> do, especially if you are asking people to look at it.

I did NOT ask people to look at it :)

I provided it in hope anyone having similar problems can verify it
also solves theirs.

> Relying on such tools is a trend these days, and that's fine because
> LLM models are tools and they can be terribly efficient when used
> well, but it does not change the review and lookup part (Postgres
> committers do that). Some people seem to have success with such
> tools, which is also fine. But please, if you plan to ask people to
> spend some time on what you are doing, the least you can do is to give
> the impression that you have yourself spent some time on the actual
> code. I cannot speak for others, but beginning a thread this way
> discourages me entirely to look at what you have sent.

Again, I thought I was very explicit tat it is not for code review,
just for verification that the concept is workable and does solve the
main issues.

I may have not been very explicit about the worst issue of
TOAST-with-index -- when you get to really large indexes that do not
fit in memory your sequential scan speeds can drop to a few tens of
lines per second because decoding each row can cause several disk
reads.

> Okay, spoiler: I did look at the code, and your LLM has just been
> hard-coding a new vartag_external, plumbing it into the TOAST
> internals without caring about any concept of backward-compatibility.

That direct plumbing was intentional to keep the code small. It was
not meant as refactoring exercise.

But the code is fully backward compatible with existing TOAST which
co-exists happily with old toast, even in the same table. The toast
flavour is chosen at the time the entry is toasted and read path just
sees another type of toast pointer abd processes it accordingly.

> Posting patches based on HEAD and not a stable branch would be a
> better idea, as well, as a starter. I understand that this is a POC,
> still.

The patch was against stable exactly because it was not meant to be
considered for inclusion yet, but for testing, possibly against a
clone of existing database.

> Please do not take it bad, this is just my opinion. I think that
> time is the most important resource we have. It is limited. However,
> beginning a thread this way does not give the impression that you
> value the time of other people at all.

I am ver sorry if I caused you to waste you time.
I tried to be explicit that this code was only for verifying the
concept of ditching the toast index.