RE: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id TYAPR01MB2990FF07F510D65DC1B6570BFE360@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Responses RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> [Results]
> Recovery/Failover performance (in seconds). 3 trial runs.
>
> | shared_buffers | master | patch  | %reg    |
> |----------------|--------|--------|---------|
> | 128MB          | 32.406 | 33.785 | 4.08%   |
> | 1GB            | 36.188 | 32.747 | -10.51% |
> | 2GB            | 41.996 | 32.88  | -27.73% |

Thanks for sharing good results.  We want to know if we can get as significant results as you gained before with
hundredsof GBs of shared buffers, don't we? 


> I also did similar benchmark performance as what Tomas did [1], simple
> "pgbench -S" tests (warmup and then 15 x 1-minute runs with 1, 8 and 16
> clients, but I'm not sure if my machine is reliable enough to produce reliable
> results for 8 clients and more.

Let me confirm just in case.  Your patch should not affect pgbench performance, but you measured it.  Is there anything
you'reconcerned about? 


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Ashutosh Bapat
Date:
Subject: Re: Dynamic gathering the values for seq_page_cost/xxx_cost