Re: Shared detoast Datum proposal - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: Shared detoast Datum proposal
Date
Msg-id CAN-LCVON0vAr6tyiK4jsLmkCPd6PxkfxzXDyG8rjM9t3jOVM6g@mail.gmail.com
Whole thread Raw
In response to Re: Shared detoast Datum proposal  (Andy Fan <zhihuifan1213@163.com>)
Responses Re: Shared detoast Datum proposal
List pgsql-hackers
Hi, Andy!

Sorry for the delay, I have had long flights this week.
I've reviewed the patch set, thank you for your efforts.
I have several notes about patch set code, but first of
I'm not sure the overall approach is the best for the task.

As Tomas wrote above, the approach is very invasive
and spreads code related to detoasting among many
parts of code.

Have you considered another one - to alter pg_detoast_datum
(actually, it would be detoast_attr function) and save
detoasted datums in the detoast context derived
from the query context? 

We have just enough information at this step to identify
the datum - toast relation id and value id, and could
keep links to these detoasted values in a, say, linked list
 or hash table. Thus we would avoid altering the executor
code and all detoast-related code would reside within
the detoast source files?

I'd check this approach in several days and would
report on the result here.

There are also comments on the code itself, I'd write them
a bit later.

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Seeking Clarification on Logical Replication Start LSN
Next
From: Tomas Vondra
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring