| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Sequence's value can be rollback after a crashed recovery. |
| Date: | 2021-11-22 19:50:42 |
| Message-ID: | DDA4CE75-758B-432E-8DD6-B7E4496687A2@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/22/21, 5:10 AM, "Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
>> The performance argument was expected before this writing. If we look at the
>> nextval_interval more carefully, we can find it would not flush the xlog every
>> time even the sequence's cachesize is 1. Currently It happens every 32 times
>> on the nextval_internal at the worst case.
>
> Right, I didn't think of that. Still, I'm -1 on this performance regression.
I periodically hear rumblings about this behavior as well. At the
very least, it certainly ought to be documented if it isn't yet. I
wouldn't mind trying my hand at that. Perhaps we could also add a new
configuration parameter if users really want to take the performance
hit.
Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Soumyadeep Chakraborty | 2021-11-22 20:09:22 | Re: Unnecessary delay in streaming replication due to replay lag |
| Previous Message | Andres Freund | 2021-11-22 19:29:56 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |