On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund <and...@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.kapil...@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 :)
>
Yes, that makes sense to me, so lets go with 1) and 2) first.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
increase_clog_bufs_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
