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
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 |