Re: suboverflowed subtransactions concurrency performance optimize - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: suboverflowed subtransactions concurrency performance optimize
Date
Msg-id EE4E9BF3-A824-4940-B13F-7448B43DA500@yandex-team.ru
Whole thread Raw
In response to suboverflowed subtransactions concurrency performance optimize  ("Pengchengliu" <pengchengliu@tju.edu.cn>)
Responses RE: suboverflowed subtransactions concurrency performance optimize  ("Pengchengliu" <pengchengliu@tju.edu.cn>)
Re: suboverflowed subtransactions concurrency performance optimize  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers
Hi Pengcheng!

You are solving important problem, thank you!

> 30 авг. 2021 г., в 13:43, Pengchengliu <pengchengliu@tju.edu.cn> написал(а):
>
> To resolve this performance problem, we think about a solution which cache
> SubtransSLRU to local cache.
> First we can query parent transaction id from SubtransSLRU, and copy the
> SLRU page to local cache page.
> After that if we need query parent transaction id again, we can query it
> from local cache directly.

A copy of SLRU in each backend's cache can consume a lot of memory. Why create a copy if we can optimise shared
representationof SLRU? 

JFYI There is a related patch to make SimpleLruReadPage_ReadOnly() faster for bigger SLRU buffers[0].
Also Nik Samokhvalov recently published interesting investigation on the topic, but for some reason his message did not
passthe moderation. [1] 

Also it's important to note that there was a community request to move SLRUs to shared_buffers [2].

Thanks!

Best regards, Andrey Borodin.

[0] https://commitfest.postgresql.org/34/2627/
[1] https://www.postgresql.org/message-id/flat/BE73A0BB-5929-40F4-BAF8-55323DE39561%40yandex-team.ru
[2] https://www.postgresql.org/message-id/flat/20180814213500.GA74618%4060f81dc409fc.ant.amazon.com


pgsql-hackers by date:

Previous
From: Kasahara Tatsuhito
Date:
Subject: Re: Error code for checksum failure in origin.c
Next
From: Bharath Rupireddy
Date:
Subject: Re: Trap errors from streaming child in pg_basebackup to exit early