| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Subject: | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
| Date: | 2024-01-31 09:31:29 |
| Message-ID: | 202401310931.omdobqqbkcll@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Looking at 0003, where an XXX comment is added about taking a spinlock
to read LogwrtResult, I suspect the answer is probably not, because it
is likely to slow down the other uses of LogwrtResult. But I wonder if
a better path forward would be to base further work on my older
uncommitted patch to make LogwrtResult use atomics. With that, you
wouldn't have to block others in order to read the value. I last posted
that patch in [1] in case you're curious.
[1] https://postgr.es/m/20220728065920.oleu2jzsatchakfj@alvherre.pgsql
The reason I abandoned that patch is that the performance problem that I
was fixing no longer existed -- it was fixed in a different way.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2024-01-31 09:40:13 | Re: CI and test improvements |
| Previous Message | Japin Li | 2024-01-31 09:27:06 | Re: Transaction timeout |