Re: [PATCH] Infinite loop while acquiring new TOAST Oid - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: [PATCH] Infinite loop while acquiring new TOAST Oid
Date
Msg-id CAN-LCVOHP+FTSg-ibCJpm=j=NnfFL0dHRYFa-ciPf+6Kg6RR=Q@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Infinite loop while acquiring new TOAST Oid  (Nikita Malakhov <hukutoc@gmail.com>)
Responses Re: [PATCH] Infinite loop while acquiring new TOAST Oid  (Gurjeet Singh <gurjeet@singh.im>)
List pgsql-hackers
Hi hackers!

Any suggestions on the previous message (64-bit toast value ID with individual counters)?

On Tue, Dec 13, 2022 at 1:41 PM Nikita Malakhov <hukutoc@gmail.com> wrote:
Hi hackers!

I've prepared a patch with a 64-bit TOAST Value ID. It is a kind of prototype
and needs some further work, but it is already working and ready to play with.

I've introduced 64-bit value ID field in varatt_external, but to keep it compatible
with older bases 64-bit value is stored as a structure of two 32-bit fields and value
ID moved to be the last in the varatt_external structure. Also, I've introduced
different ID assignment function - instead of using global OID assignment function
I use individual counters for each TOAST table, automatically cached and after
server restart when new value is inserted into TOAST table maximum used value
is searched and used to assign the next one.

>Andres Freund:

>I think we'll need to do something about the width of varatt_external to make
>the conversion to 64bit toast oids viable - and if we do, I don't think
>there's a decent argument for staying with 4 byte toast OIDs. I think the
>varatt_external equivalent would end up being smaller in just about all cases.
>And as you said earlier, the increased overhead inside the toast table / index
>is not relevant compared to the size of toasted datums.

There is some small overhead due to indexing 64-bit values. Also, for smaller
tables we can use 32-bit ID instead of 64-bit, but then we would have a problem
when we reach the limit of 2^32.

Pg_upgrade seems to be not a very difficult case if we go keeping old TOAST
tables using 32-bit values,

Please have a look. I'd be grateful for some further directions.

GIT branch with this feature, rebased onto current master:


--
Regards,
Nikita Malakhov
Postgres Professional 

pgsql-hackers by date:

Previous
From: Eric Radman
Date:
Subject: Re: [PATCH] Add function to_oct
Next
From: Peter Geoghegan
Date:
Subject: Re: Call lazy_check_wraparound_failsafe earlier for parallel vacuum