Message-ID: <b652ce45-8d85-fe78-2914-8993692c2ee0@oss.nttdata.com>
Date: Tue, 28 Dec 2021 15:56:22 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.4.1
Subject: Re: sequences vs. synchronous replication
Content-Language: en-US
To: Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com,
 pgsql-hackers@lists.postgresql.org
References: <a58f1c38-10eb-7d7f-372c-cfb95007d54e@enterprisedb.com>
 <20211224.143725.1750248643492340056.horikyota.ntt@gmail.com>
 <ad83e515-44f6-4691-8fe0-503b94499ed5@enterprisedb.com>
 <20211224.170451.116141220257426861.horikyota.ntt@gmail.com>
 <27f005a6-63f7-2ca9-2ab3-92fe9110e224@enterprisedb.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
In-Reply-To: <27f005a6-63f7-2ca9-2ab3-92fe9110e224@enterprisedb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b652ce45-8d85-fe78-2914-8993692c2ee0%40oss.nttdata.com>
Precedence: bulk


On 2021/12/24 19:40, Tomas Vondra wrote:
> Maybe, but what would such workload look like? Based on the tests I did, such workload probably can't generate any WAL. The amount of WAL added by the change is tiny, the regression is caused by having to flush WAL.
> 
> The only plausible workload I can think of is just calling nextval, and the cache pretty much fixes that.

Some users don't want to increase cache setting, do they? Because

- They may expect that setval() affects all subsequent nextval(). But if cache is set to greater than one, the value set by setval() doesn't affect other backends until they consumed all the cached sequence values.
- They may expect that the value returned from nextval() is basically increased monotonically. If cache is set to greater than one, subsequent nextval() can easily return smaller value than one returned by previous nextval().
- They may want to avoid "hole" of a sequence as much as possible, e.g., as far as the server is running normally. If cache is set to greater than one, such "hole" can happen even thought the server doesn't crash yet.


> FWIW I plan to explore the idea of looking at sequence page LSN, and flushing up to that position.

Sounds great, thanks!

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION