Re: Slow standby snapshot

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: x4mmm(at)yandex-team(dot)ru
Cc: michail(dot)nikolaev(at)gmail(dot)com, aekorotkov(at)gmail(dot)com, andres(at)anarazel(dot)de, reshkekirill(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Slow standby snapshot
Date: 2022-07-27 07:08:07
Message-ID: 20220727.160807.1746105134891096510.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 26 Jul 2022 23:09:16 +0500, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote in
>
>
> > On 20 Jul 2022, at 02:12, Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> wrote:
> >
> >> I've looked into v5.
> > Thanks!
> >
> > Patch is updated accordingly your remarks.
>
> The patch seems Ready for Committer from my POV.

+ * is s updated during taking the snapshot. The KnownAssignedXidsNextOffset
+ * contains not an offset to the next valid xid but a number which tends to
+ * the offset to next valid xid. KnownAssignedXidsNextOffset[] values read

Is there still a reason why the array stores the distnace to the next
valid element instead of the index number of the next valid index? It
seems to me that that was in an intention to reduce the size of the
offset array but it is int32[] which is far wider than
TOTAL_MAX_CACHED_SUBXIDS.

It seems to me storing the index itself is simpler and maybe faster by
the cycles to perform addition.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-07-27 07:35:24 Re: Improving btree performance through specializing by key shape, take 2
Previous Message Justin Pryzby 2022-07-27 06:44:25 Re: Cygwin cleanup