Re: Speed up Clog Access by increasing CLOG buffers
| От | Amit Kapila |
|---|---|
| Тема | Re: Speed up Clog Access by increasing CLOG buffers |
| Дата | |
| Msg-id | CAA4eK1L2KO18G5-ajNitztnmn1G_Ex1N4oUHhF0Xx3QrY57Ufw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
Re: Speed up Clog Access by increasing CLOG buffers |
| Список | pgsql-hackers |
On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund <andres@anarazel.de> wrote:
>
> On 2016-03-28 22:50:49 +0530, Amit Kapila wrote:
> > On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> > >
>
> Amit, could you run benchmarks on your bigger hardware? Both with
> USE_CONTENT_LOCK commented out and in?
>
>
> On 2016-03-28 22:50:49 +0530, Amit Kapila wrote:
> > On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> > >
>
> Amit, could you run benchmarks on your bigger hardware? Both with
> USE_CONTENT_LOCK commented out and in?
>
Yes.
> I think we should go for 1) and 2) unconditionally.
Yes, that makes sense. On 20 min read-write pgbench --unlogged-tables benchmark, I see that with HEAD Tps is 36241 and with increase the clog buffers patch, Tps is 69340 at 128 client count (very good performance boost) which indicates that we should go ahead with 1) and 2) patches.
0002-Increase-max-number-of-buffers-in-clog-SLRU-to-128
Size
CLOGShmemBuffers(void)
{
- return Min(32, Max(4, NBuffers / 512));
+ return Min(128, Max(4, NBuffers / 512));
}
I think we should change comments on top of this function. I have changed the comments as per my previous patch and attached the modified patch with this mail, see if that makes sense.
0001-Improve-64bit-atomics-support
+#if 0
+#ifndef PG_HAVE_ATOMIC_READ_U64
+#define PG_HAVE_ATOMIC_READ_U64
+static inline uint64
What the purpose of above #if 0? Other than that patch looks good to me.
> And then evaluate
> whether to go with your, or 3) from above. If the latter, we've to do
> some cleanup :)
>
> whether to go with your, or 3) from above. If the latter, we've to do
> some cleanup :)
>
Yes, that makes sense to me, so lets go with 1) and 2) first.
Вложения
В списке pgsql-hackers по дате отправления: