| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Slow standby snapshot |
| Date: | 2021-08-02 22:01:55 |
| Message-ID: | 20210802220155.v7snujae3zj5anhd@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-08-03 00:07:23 +0300, Michail Nikolaev wrote:
> The main idea is simple optimistic optimization - store offset to next
> valid entry. So, in most cases, we could just skip all the gaps.
> Of course, it adds some additional impact for workloads without long
> (few seconds) transactions but it is almost not detectable (because of
> CPU caches).
I'm doubtful that that's really the right direction. For workloads that
are replay heavy we already often can see the cost of maintaining the
known xids datastructures show up significantly - not surprising, given
the datastructure. And for standby workloads with active primaries the
cost of searching through the array in all backends is noticeable as
well. I think this needs a bigger data structure redesign.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-08-02 22:11:39 | Re: make MaxBackends available in _PG_init |
| Previous Message | Bossart, Nathan | 2021-08-02 21:57:18 | Re: make MaxBackends available in _PG_init |