> On 7 Apr 2024, at 21:41, Alvaro Herrera wrote:
>
> Well, it would be nice to have *some* test, but as you say it is way
> more complex than the thing being tested, and it zooms in on the
> functioning of the multixact creation in insane quantum-physics ways ...
> to the point that you can
On 2024-Feb-03, Andrey M. Borodin wrote:
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
> Cost of having this test:
> 1. We need a new injection point type "wait" (in addition to "error" and
> "notice"). It
> On 6 Apr 2024, at 14:24, Andrey M. Borodin wrote:
>
> What do you think?
OK, I'll follow this plan.
As long as most parts of this thread were committed, I'll mark CF item as
"committed".
Thanks to everyone involved!
See you in a followup thread about sleeping on CV.
Best regards, Andrey
> On 29 Feb 2024, at 06:59, Kyotaro Horiguchi wrote:
>
> At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
> wrote in
>> Here's the test draft. This test reliably reproduces sleep on CV when
>> waiting next multixact to be filled into "members" SLRU.
>
> By the way, I raised a
At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
wrote in
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
By the way, I raised a question about using multiple CVs
simultaneously [1]. That is, I suspect
> On 28 Jan 2024, at 23:17, Andrey M. Borodin wrote:
>
>
>> Perhaps a test to make the code reach the usleep(1000) can be written
>> using injection points (49cd2b93d7db)?
>
> I've tried to prototype something like that. But interesting point between
> GetNewMultiXactId() and
> On 28 Jan 2024, at 17:49, Alvaro Herrera wrote:
>
> I'd appreciate it if you or Horiguchi-san can update his patch to remove
> use of usleep in favor of a CV in multixact, and keep this CF entry to
> cover it.
Sure! Sounds great!
> Perhaps a test to make the code reach the usleep(1000) can
On 2024-Jan-27, Andrey Borodin wrote:
> thanks for the ping! Most important parts of this patch set are discussed in
> [0]. If that patchset will be committed, I'll withdraw entry for this thread
> from commitfest.
> There's a version of Multixact-specific optimizations [1], but I hope they
>
> On 20 Jan 2024, at 08:31, vignesh C wrote:
>
> On Mon, 9 Jan 2023 at 09:49, Andrey Borodin wrote:
>>
>> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
>>> does not apply on top of HEAD as in [1], please post a rebased patch:
>>>
>> Thanks! Here's the rebase.
>
> I'm seeing that there
On Mon, 9 Jan 2023 at 09:49, Andrey Borodin wrote:
>
> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > does not apply on top of HEAD as in [1], please post a rebased patch:
> >
> Thanks! Here's the rebase.
I'm seeing that there has been no activity in this thread for more
than 1 year now,
Hi Dilip! Thank you for the review!
On Tue, Jan 10, 2023 at 9:58 PM Dilip Kumar wrote:
>
> On Mon, Jan 9, 2023 at 9:49 AM Andrey Borodin wrote:
> >
> > On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > > does not apply on top of HEAD as in [1], please post a rebased patch:
> > >
> > Thanks!
On Mon, Jan 9, 2023 at 9:49 AM Andrey Borodin wrote:
>
> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > does not apply on top of HEAD as in [1], please post a rebased patch:
> >
> Thanks! Here's the rebase.
I was looking into this patch, it seems like three different
optimizations are
On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> does not apply on top of HEAD as in [1], please post a rebased patch:
>
Thanks! Here's the rebase.
Best regards, Andrey Borodin.
v24-0001-Divide-SLRU-buffers-into-8-associative-banks.patch
Description: Binary data
On Fri, 19 Aug 2022 at 21:18, wrote:
>
> Andrey Borodin wrote 2022-08-18 06:35:
> >
> > I like the idea of one knob instead of one per each SLRU. Maybe we
> > even could deduce sane value from NBuffers? That would effectively
> > lead to 0 knobs :)
> >
> > Your patch have a prefix "v22-0006",
On Sat, Jul 23, 2022 at 1:48 AM Thomas Munro wrote:
>
> On Sat, Jul 23, 2022 at 8:41 PM Andrey Borodin wrote:
> > Thomas, do you still have any doubts? Or is it certain that SLRU will be
> > replaced by any better subsystem in 16?
>
> Hi Andrey,
>
> Sorry for my lack of replies on this and the
Andrey Borodin wrote 2022-08-18 06:35:
I like the idea of one knob instead of one per each SLRU. Maybe we
even could deduce sane value from NBuffers? That would effectively
lead to 0 knobs :)
Your patch have a prefix "v22-0006", does it mean there are 5 previous
steps of the patchset?
Thank
> On 17 Aug 2022, at 00:36, i.laza...@postgrespro.ru wrote:
>
>> Andrey Borodin wrote 2022-07-23 11:39:
>> Yura, thank you for your benchmarks!
>> We already knew that patch can save the day on pathological workloads,
>> now we have a proof of this.
>> Also there's the evidence that user can
Andrey Borodin wrote 2022-07-23 11:39:
Yura, thank you for your benchmarks!
We already knew that patch can save the day on pathological workloads,
now we have a proof of this.
Also there's the evidence that user can blindly increase size of SLRU
if they want (with the second patch). So there's
On Sat, Jul 23, 2022 at 8:41 PM Andrey Borodin wrote:
> Thomas, do you still have any doubts? Or is it certain that SLRU will be
> replaced by any better subsystem in 16?
Hi Andrey,
Sorry for my lack of replies on this and the other SLRU thread -- I'm
thinking and experimenting. More soon.
> On 21 Jul 2022, at 18:00, Yura Sokolov wrote:
>
> In this case simple buffer increase does help. But "buckets"
> increase performance gain.
Yura, thank you for your benchmarks!
We already knew that patch can save the day on pathological workloads, now we
have a proof of this.
Also there's
Good day, all.
I did benchmark of patch on 2 socket Xeon 5220 CPU @ 2.20GHz .
I used "benchmark" used to reproduce problems with SLRU on our
customers setup.
In opposite to Shawn's tests I concentrated on bad case: a lot
of contention.
slru-funcs.sql - function definitions
- functions creates
> On 20 Feb 2022, at 02:38, Thomas Munro wrote:
>
> Back to this patch: assuming we can settle on a good-enough-for-now
> replacement algorithm, do we want to add this set of 7 GUCs? Does
> anyone else want to weigh in on that?
Hi Thomas!
It seems we don't have any other input besides
> On 20 Feb 2022, at 02:42, Andres Freund wrote:
>
> On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
>> Back to this patch: assuming we can settle on a good-enough-for-now
>> replacement algorithm, do we want to add this set of 7 GUCs? Does
>> anyone else want to weigh in on that?
>
> I'm
On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
> Back to this patch: assuming we can settle on a good-enough-for-now
> replacement algorithm, do we want to add this set of 7 GUCs? Does
> anyone else want to weigh in on that?
I'm -0.2 on it, given that we have a better path forward.
On Sat, Feb 19, 2022 at 6:34 PM Andrey Borodin wrote:
> There's feature freeze approaching again. I see that you are working on
> moving SLRUs to buffer pools, but it is not clear to which PG version it will
> land. And there is 100% consensus that first patch is useful and helps to
> prevent
> 8 апр. 2021 г., в 17:22, Thomas Munro написал(а):
>
> Thanks! I chickened out of committing a buffer replacement algorithm
> patch written 11 hours before the feature freeze, but I also didn't
> really want to commit the GUC patch without that. Ahh, if only we'd
> latched onto the real
> 21 янв. 2022 г., в 05:19, Shawn Debnath написал(а):
>
> On Thu, Jan 20, 2022 at 09:21:24PM +0500, Andrey Borodin wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content
> 20 янв. 2022 г., в 20:44, Shawn Debnath написал(а):
>
> If my test workload can be made better, please let me know. Happy to
> re-run tests as needed.
Shawn, thanks for the benchmarking!
Can you please also test 2nd patch against a large multixact SLRUs?
2nd patch is not intended to do
> 15 янв. 2022 г., в 20:46, Justin Pryzby написал(а):
>>>
>>> I was planning on running a set of stress tests on these patches. Could
>>> we confirm which ones we plan to include in the commitfest?
>>
>> Many thanks for your interest. Here's the latest version.
>
> This is failing to
On Sat, Jan 15, 2022 at 12:16:59PM +0500, Andrey Borodin wrote:
> > 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
> > On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
> >>> PFA rebase of the patchset. Also I've added a patch to combine
> >>> page_number, page_status, and
> 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
>
> On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
>>> PFA rebase of the patchset. Also I've added a patch to combine
>>> page_number, page_status, and page_dirty together to touch less
>>> cachelines.
>>
>> The cfbot
Hi,
On Sun, Dec 26, 2021 at 03:09:59PM +0500, Andrey Borodin wrote:
>
>
> PFA rebase of the patchset. Also I've added a patch to combine page_number,
> page_status, and page_dirty together to touch less cachelines.
The cfbot reports some errors on the latest version of the patch:
>> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а):
>>
> I have one more idea inspired by CPU caches.
> Let's make SLRU n-associative, where n ~ 8.
> We can divide buffers into "banks", number of banks must be power of 2.
> All banks are of equal size. We choose bank size to approximately
пн, 14 июн. 2021 г. в 15:07, Andrey Borodin :
> PFA patch implementing this idea.
>
I'm benchmarked v17 patches.
Testing was done on a 96-core machine, with PGDATA completely placed in
tmpfs.
PostgreSQL was built with CFLAGS -O2.
for-update PgBench script:
\set aid random_zipfian(1, 100, 2)
> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а):
>
> On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote:
>> I agree that this version of eviction seems much more effective and less
>> intrusive than RR. And it's still LRU, which is important for subsystem that
>> is called SLRU.
>>
On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote:
> I agree that this version of eviction seems much more effective and less
> intrusive than RR. And it's still LRU, which is important for subsystem that
> is called SLRU.
> shared->search_slotno is initialized implicitly with memset(). But
> 8 апр. 2021 г., в 03:30, Thomas Munro написал(а):
>
> Here's another approach that is a little less exciting than
> "tournament RR" (or whatever that should be called; I couldn't find an
> established name for it). This version is just our traditional linear
> search, except that it stops
On Thu, Apr 8, 2021 at 12:13 AM Andrey Borodin wrote:
> > 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а):
> > Maybe instead of fully associative cache with random replacement we could
> > use 1-associative cache?
> > i.e. each page can reside only in one spcific buffer slot. If there's
> >
> 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а):
>
> Maybe instead of fully associative cache with random replacement we could use
> 1-associative cache?
> i.e. each page can reside only in one spcific buffer slot. If there's
> something else - evict it.
> I think this would be as
> 7 апр. 2021 г., в 08:59, Thomas Munro написал(а):
>
> The remaining thing that bothers me about this patch set is that there is
> still a linear search in the replacement algorithm, and it runs with an
> exclusive lock. That creates a serious problem for large caches that still
> aren't
On Sun, Apr 4, 2021 at 7:57 AM Andrey Borodin wrote:
> I was toying around with big values. For example if we set different big
xact_buffers we can get something like
> FATAL: not enough shared memory for data structure "Notify" (72768 bytes
requested)
> FATAL: not enough shared memory for data
> 1 апр. 2021 г., в 06:40, Thomas Munro написал(а):
>
> 2. Remove the cap of 128 buffers for xact_buffers as agreed. We
> still need a cap though, to avoid a couple of kinds of overflow inside
> slru.c, both when computing the default value and accepting a
> user-provided number. I
On Thu, Apr 1, 2021 at 10:09 AM Andrey Borodin wrote:
> > 29 марта 2021 г., в 11:26, Andrey Borodin написал(а):
> > My TODO list:
> > 1. Try to break patch set v13-[0001-0004]
> > 2. Think how to measure performance of linear search versus hash search in
> > SLRU buffer mapping.
>
> Hi Thomas!
> 29 марта 2021 г., в 11:26, Andrey Borodin написал(а):
>
> My TODO list:
> 1. Try to break patch set v13-[0001-0004]
> 2. Think how to measure performance of linear search versus hash search in
> SLRU buffer mapping.
Hi Thomas!
I'm still doing my homework. And to this moment all my catch is
> 29 марта 2021 г., в 02:15, Thomas Munro написал(а):
>
> On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote:
>>> 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
>>> , and murmurhash which is inlineable and
>>> branch-free.
>
>> I think pageno is a hash already. Why hash any further?
On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote:
> > 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
> > , and murmurhash which is inlineable and
> > branch-free.
> I think pageno is a hash already. Why hash any further? And pages accessed
> together will have smaller access time due
> 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
>
> On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin wrote:
>> Some thoughts on HashTable patch:
>> 1. Can we allocate bigger hashtable to reduce probability of collisions?
>
> Yeah, good idea, might require some study.
In a long run we
On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin wrote:
> Some thoughts on HashTable patch:
> 1. Can we allocate bigger hashtable to reduce probability of collisions?
Yeah, good idea, might require some study.
> 2. Can we use specialised hashtable for this case? I'm afraid hash_search()
> does
> 26 марта 2021 г., в 11:00, Andrey Borodin написал(а):
>
>> I'm not saying the 0002 patch is bug-free yet though, it's a bit finickity.
> I think the idea of speeding up linear search is really really good for
> scaling SLRUs. It's not even about improving normal performance of the
>
Hi Thomas, Gilles, all!
Thanks for reviewing this!
> 25 марта 2021 г., в 02:31, Thomas Munro написал(а):
>
> I don't think we should put "slru" (the name of the buffer replacement
> algorithm, implementation detail) in the GUC names.
+1
> +It defaults to 0, in this case CLOG size is
Hi Andrey, all,
I propose some changes, and I'm attaching a new version:
I renamed the GUCs as clog_buffers etc (no "_slru_"). I fixed some
copy/paste mistakes where the different GUCs were mixed up. I made
some changes to the .conf.sample. I rewrote the documentation so that
it states the
On Thu, Mar 25, 2021 at 10:31 AM Thomas Munro wrote:
> We already know that increasing the number of CLOG buffers above the
> current number hurts as the linear search begins to dominate
> (according to the commit message for 5364b357), and it doesn't seem
> great to ship a new feature that melts
Hi Andrey,
On Sat, Mar 13, 2021 at 1:44 AM Andrey Borodin wrote:
> [v10]
+intmultixact_offsets_slru_buffers = 8;
+intmultixact_members_slru_buffers = 16;
+intsubtrans_slru_buffers = 32;
+intnotify_slru_buffers = 8;
+int
Le 12/03/2021 à 13:44, Andrey Borodin a écrit :
>
>> 11 марта 2021 г., в 20:50, Gilles Darold написал(а):
>>
>>
>> The patch doesn't apply anymore in master cause of error: patch failed:
>> src/backend/utils/init/globals.c:150
>>
>>
>>
>> An other remark about this patch is that it should be
> 11 марта 2021 г., в 20:50, Gilles Darold написал(а):
>
>
> The patch doesn't apply anymore in master cause of error: patch failed:
> src/backend/utils/init/globals.c:150
>
>
>
> An other remark about this patch is that it should be mentionned in the
> documentation
Le 15/02/2021 à 18:17, Andrey Borodin a écrit :
23 дек. 2020 г., в 21:31, Gilles Darold написал(а):
Sorry for the response delay, we have run several others tests trying to figure
out the performances gain per patch but unfortunately we have very heratic
results. With the same parameters
> 23 дек. 2020 г., в 21:31, Gilles Darold написал(а):
>
> Sorry for the response delay, we have run several others tests trying to
> figure out the performances gain per patch but unfortunately we have very
> heratic results. With the same parameters and patches the test doesn't
> returns
Le 13/12/2020 à 18:24, Andrey Borodin a écrit :
13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
I've done more review on these patches.
Thanks, Gilles! I'll incorporate all your fixes to patchset.
Can you also benchmark conditional variable sleep? The patch "Add conditional
variable to
> 13 дек. 2020 г., в 22:24, Andrey Borodin написал(а):
>
>
>
>> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
>>
>> I've done more review on these patches.
>
> Thanks, Gilles! I'll incorporate all your fixes to patchset.
PFA patches.
Also, I've noted that patch "Add conditional
> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
>
> I've done more review on these patches.
Thanks, Gilles! I'll incorporate all your fixes to patchset.
Can you also benchmark conditional variable sleep? The patch "Add conditional
variable to wait for next MultXact offset in corner
Le 11/12/2020 à 18:50, Gilles Darold a écrit :
> Le 10/12/2020 à 15:45, Gilles Darold a écrit :
>> Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
>>> Hi Gilles!
>>>
>>> Many thanks for your message!
>>>
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is
Le 10/12/2020 à 15:45, Gilles Darold a écrit :
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patches for
Le 09/12/2020 à 11:51, Gilles Darold a écrit :
Also PG regression tests are failing too on several part.
Forget this, I have not run the regression tests in the right repository:
...
===
All 189 tests passed.
===
I'm looking why the application is
Hi Andrey,
Thanks for the backport. I have issue with the first patch "Use shared
lock in GetMultiXactIdMembers for offsets and members"
(v1106-0001-Use-shared-lock-in-GetMultiXactIdMembers-for-o.patch) the
applications are not working anymore when I'm applying it. Also PG
regression tests
Hi Gilles!
Many thanks for your message!
> 8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
>
> I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patches for PG11. Can you please benchmark them (without
Le 13/11/2020 à 12:49, Andrey Borodin a écrit :
10 нояб. 2020 г., в 23:07, Tomas Vondra
написал(а):
On 11/10/20 7:16 AM, Andrey Borodin wrote:
but this picture was not stable.
Seems we haven't made much progress in reproducing the issue :-( I guess
we'll need to know more about the
> 10 нояб. 2020 г., в 23:07, Tomas Vondra
> написал(а):
>
> On 11/10/20 7:16 AM, Andrey Borodin wrote:
>>
>>
>> but this picture was not stable.
>>
>
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens.
On Wed, Nov 11, 2020 at 7:07 AM Tomas Vondra
wrote:
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens. Is there
> anything special about the hardware/config? Are you monitoring size of
> the pg_multixact
On 11/10/20 7:16 AM, Andrey Borodin wrote:
>
>
>> 10 нояб. 2020 г., в 05:13, Tomas Vondra
>> написал(а):
>> After the issue reported in [1] got fixed, I've restarted the multi-xact
>> stress test, hoping to reproduce the issue. But so far no luck :-(
>
>
> Tomas, many thanks for looking
> 10 нояб. 2020 г., в 05:13, Tomas Vondra
> написал(а):
> After the issue reported in [1] got fixed, I've restarted the multi-xact
> stress test, hoping to reproduce the issue. But so far no luck :-(
Tomas, many thanks for looking into this. I figured out that to make multixact
sets bigger
Hi,
After the issue reported in [1] got fixed, I've restarted the multi-xact
stress test, hoping to reproduce the issue. But so far no luck :-(
I've started slightly different tests on two machines - on one machine
I've done this:
a) init.sql
create table t (a int);
insert into t select
> 29 окт. 2020 г., в 18:49, Tomas Vondra
> написал(а):
>
> On Thu, Oct 29, 2020 at 12:08:21PM +0500, Andrey Borodin wrote:
>>
>>
>>> 29 окт. 2020 г., в 04:32, Tomas Vondra
>>> написал(а):
>>>
>>> It's not my intention to be mean or anything like that, but to me this
>>> means we don't
On Thu, Oct 29, 2020 at 12:08:21PM +0500, Andrey Borodin wrote:
29 окт. 2020 г., в 04:32, Tomas Vondra
написал(а):
It's not my intention to be mean or anything like that, but to me this
means we don't really understand the problem we're trying to solve. Had
we understood it, we should be
Hi,
On Wed, Oct 28, 2020 at 12:34:58PM +0500, Andrey Borodin wrote:
Tomas, thanks for looking into this!
28 окт. 2020 г., в 06:36, Tomas Vondra
написал(а):
This thread started with a discussion about making the SLRU sizes
configurable, but this patch version only adds a local cache. Does
On Wed, Oct 28, 2020 at 10:36:39PM +0300, Alexander Korotkov wrote:
Hi, Tomas!
Thank you for your review.
On Wed, Oct 28, 2020 at 4:36 AM Tomas Vondra
wrote:
I did a quick review on this patch series. A couple comments:
0001
This looks quite suspicious to me -
Hi, Tomas!
Thank you for your review.
On Wed, Oct 28, 2020 at 4:36 AM Tomas Vondra
wrote:
> I did a quick review on this patch series. A couple comments:
>
>
> 0001
>
>
> This looks quite suspicious to me - SimpleLruReadPage_ReadOnly is
> changed to return information about what lock was
Tomas, thanks for looking into this!
> 28 окт. 2020 г., в 06:36, Tomas Vondra
> написал(а):
>
>
> This thread started with a discussion about making the SLRU sizes
> configurable, but this patch version only adds a local cache. Does this
> achieve the same goal, or would we still gain
On Tue, Oct 27, 2020 at 08:23:26PM +0300, Alexander Korotkov wrote:
On Tue, Oct 27, 2020 at 8:02 PM Alexander Korotkov wrote:
On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> Thanks for your review, Alexander!
> +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> Other
On Tue, Oct 27, 2020 at 8:02 PM Alexander Korotkov wrote:
> On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> > Thanks for your review, Alexander!
> > +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> > Other changes seem correct to me too.
> >
> >
> > I've tried to find
On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> Thanks for your review, Alexander!
> +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> Other changes seem correct to me too.
>
>
> I've tried to find optimal value for cache size and it seems to me that it
> affects
> 26 окт. 2020 г., в 06:05, Alexander Korotkov
> написал(а):
>
> Hi!
>
> On Mon, Sep 28, 2020 at 5:41 PM Andrey M. Borodin
> wrote:
>>> 28 авг. 2020 г., в 23:08, Anastasia Lubennikova
>>> написал(а):
>>>
>>> 1) The first patch is sensible and harmless, so I think it is ready for
>>>
Hi!
On Mon, Sep 28, 2020 at 5:41 PM Andrey M. Borodin wrote:
> > 28 авг. 2020 г., в 23:08, Anastasia Lubennikova
> > написал(а):
> >
> > 1) The first patch is sensible and harmless, so I think it is ready for
> > committer. I haven't tested the performance impact, though.
> >
> > 2) I like
On 28.09.2020 17:41, Andrey M. Borodin wrote:
Hi, Anastasia!
28 авг. 2020 г., в 23:08, Anastasia Lubennikova
написал(а):
1) The first patch is sensible and harmless, so I think it is ready for
committer. I haven't tested the performance impact, though.
2) I like the initial proposal to
Hi, Anastasia!
> 28 авг. 2020 г., в 23:08, Anastasia Lubennikova
> написал(а):
>
> 1) The first patch is sensible and harmless, so I think it is ready for
> committer. I haven't tested the performance impact, though.
>
> 2) I like the initial proposal to make various SLRU buffers
On 08.07.2020 10:03, Andrey M. Borodin wrote:
2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а):
On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
Generally in such cases, condition variables would work. In the
attached PoC, the reader side gets no penalty in the "likely" code
path.
> On 8 Jul 2020, at 09:03, Andrey M. Borodin wrote:
>
>
>
>> 2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а):
>>
>>> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
>>
>>> Generally in such cases, condition variables would work. In the
>>> attached PoC, the reader side gets no
> 2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а):
>
>> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
>
>> Generally in such cases, condition variables would work. In the
>> attached PoC, the reader side gets no penalty in the "likely" code
>> path. The writer side always calls
> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
> Generally in such cases, condition variables would work. In the
> attached PoC, the reader side gets no penalty in the "likely" code
> path. The writer side always calls ConditionVariableBroadcast but the
> waiter list is empty in almost
At Fri, 15 May 2020 14:01:46 +0500, "Andrey M. Borodin"
wrote in
>
>
> > 15 мая 2020 г., в 05:03, Kyotaro Horiguchi
> > написал(а):
> >
> > At Thu, 14 May 2020 11:44:01 +0500, "Andrey M. Borodin"
> > wrote in
> >>> GetMultiXactIdMembers believes that 4 is successfully done if 2
> >>>
> 15 мая 2020 г., в 05:03, Kyotaro Horiguchi
> написал(а):
>
> At Thu, 14 May 2020 11:44:01 +0500, "Andrey M. Borodin"
> wrote in
>>> GetMultiXactIdMembers believes that 4 is successfully done if 2
>>> returned valid offset, but actually that is not obvious.
>>>
>>> If we add a single
At Thu, 14 May 2020 11:44:01 +0500, "Andrey M. Borodin"
wrote in
> > GetMultiXactIdMembers believes that 4 is successfully done if 2
> > returned valid offset, but actually that is not obvious.
> >
> > If we add a single giant lock just to isolate ,say,
> > GetMultiXactIdMember and
> 14 мая 2020 г., в 11:16, Kyotaro Horiguchi
> написал(а):
>
> At Thu, 14 May 2020 10:19:42 +0500, "Andrey M. Borodin"
> wrote in
I'm looking more at MultiXact and it seems to me that we have a race
condition there.
When we create a new MultiXact we do:
1.
At Thu, 14 May 2020 10:19:42 +0500, "Andrey M. Borodin"
wrote in
> >> I'm looking more at MultiXact and it seems to me that we have a race
> >> condition there.
> >>
> >> When we create a new MultiXact we do:
> >> 1. Generate new MultiXactId under MultiXactGenLock
> >> 2. Record new mxid with
> 14 мая 2020 г., в 06:25, Kyotaro Horiguchi
> написал(а):
>
> At Wed, 13 May 2020 23:08:37 +0500, "Andrey M. Borodin"
> wrote in
>>
>>
>>> 11 мая 2020 г., в 16:17, Andrey M. Borodin
>>> написал(а):
>>>
>>> I've went ahead and created 3 patches:
>>> 1. Configurable SLRU buffer sizes
At Wed, 13 May 2020 23:08:37 +0500, "Andrey M. Borodin"
wrote in
>
>
> > 11 мая 2020 г., в 16:17, Andrey M. Borodin
> > написал(а):
> >
> > I've went ahead and created 3 patches:
> > 1. Configurable SLRU buffer sizes for MultiXacOffsets and MultiXactMembers
> > 2. Reduce locking level to
> 11 мая 2020 г., в 16:17, Andrey M. Borodin написал(а):
>
> I've went ahead and created 3 patches:
> 1. Configurable SLRU buffer sizes for MultiXacOffsets and MultiXactMembers
> 2. Reduce locking level to shared on read of MultiXactId members
> 3. Configurable cache size
I'm looking more at
> 8 мая 2020 г., в 21:36, Andrey M. Borodin написал(а):
>
> *** The problem ***
> I'm investigating some cases of reduced database performance due to
> MultiXactOffsetLock contention (80% MultiXactOffsetLock, 20% IO DataFileRead).
> The problem manifested itself during index repack and
Hi, hackers!
*** The problem ***
I'm investigating some cases of reduced database performance due to
MultiXactOffsetLock contention (80% MultiXactOffsetLock, 20% IO DataFileRead).
The problem manifested itself during index repack and constraint validation.
Both being effectively full table
99 matches
Mail list logo
