On 4/26/21 9:27 PM, Andres Freund wrote:
> Hi,
>
> On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
>> I'm not sure what to do about this :-( I don't have any ideas about how to
>> eliminate this overhead, so the only option I see is reverting the changes
>> in heap_insert. Unfortunately, that'd mean inserts into TOAST tables won't
>> be frozen ...
>
> ISTM that the fundamental issue here is not that we acquire pins that we
> shouldn't, but that we do so at a much higher frequency than needed.
>
> It's probably too invasive for 14, but I think it might be worth exploring
> passing down a BulkInsertState in nodeModifyTable.c's table_tuple_insert() iff
> the input will be more than one row.
>
> And then add the vm buffer of the target page to BulkInsertState, so that
> hio.c can avoid re-pinning the buffer.
>
Yeah. The question still is what to do about 14, though. Shall we leave
the code as it is now, or should we change it somehow? It seem a bit
unfortunate that a COPY FREEZE optimization should negatively influence
other (more) common use cases, so I guess we can't just keep the current
code ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
