| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | michael(at)paquier(dot)xyz |
| Cc: | andres(at)anarazel(dot)de, alvherre(at)2ndquadrant(dot)com, amit(dot)kapila16(at)gmail(dot)com, jeff(dot)janes(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Coding in WalSndWaitForWal |
| Date: | 2019-11-13 08:18:10 |
| Message-ID: | 20191113.171810.985192835121707471.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ah, my stupid.
At Wed, 13 Nov 2019 16:34:49 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Tue, Nov 12, 2019 at 11:27:16AM -0800, Andres Freund wrote:
> > It seems to me it'd be better to just remove the "get a more recent
> > flush pointer" block - it doesn't seem to currently surve a meaningful
> > purpose.
>
> +1. That was actually my suggestion upthread :)
Actually it is useless as it is. But the code still seems to me an
incomplete fast path (that lacks immediate return after it) for the
case where just one call to GetFlushRecPtr advances RecentFlushPtr is
enough.
However, I'm not confident taht removing the (intended) fast path
impacts perforance significantly. So I don't object to remove it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2019-11-13 08:33:58 | Re: Recovery performance of DROP DATABASE with many tablespaces |
| Previous Message | Dilip Kumar | 2019-11-13 08:13:41 | Re: [HACKERS] Block level parallel vacuum |