Horton

Re: Speed up Clog Access by increasing CLOG buffers

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-04-08T07:37:05Z
Lists: pgsql-hackers

Attachments

On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund <andres@anarazel.de> wrote:

> On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
>
> > This is the data with -b tpcb-like@1 with 20-min run for each version
> and I
> > could see almost similar results as the data posted in previous e-mail.
> >
> > Client Count/Patch_ver (tps) 256
> > clog_buf_128 40617
> > clog_buf_128 +group_clog_v8 51137
> > clog_buf_128 +content_lock 54188
> >
> > For -b select-only@3,  I have done quicktest for each version and
> number is
> > same 62K~63K for all version, why do you think this will improve
> > select-only workload?
>
> What I was looking for was pgbench with both -btpcb-like@1
> -bselect-only@3 specified; i.e. a mixed read/write test.


I have taken the data in the suggested way and the performance seems to be
neutral for both the patches.  Detailed data for all the runs for three
versions is attached.

Median of 3 20-minutes run.

Client Count/Patch_ver (tps) 256
clog_buf_128 110630
clog_buf_128 +group_clog_v8 111575
clog_buf_128 +content_lock 96581


Now, from above data, it appears that content lock patch has some
regression, but if you see in detailed data attached with this mail, the
highest TPS is close to other patches, but still on the lesser side.



> In my
> measurement that's where Simon's approach shines (not surprising if you
> look at the way it works), and it's of immense practical importance -
> most workloads are mixed.
>
>
I have tried above tests two times, but didn't notice any gain with content
lock approach.


I think by now, we have done many tests with both approaches and we find
that in some cases, it is slightly better and in most cases it is neutral
and in some cases it is worse than group clog approach.  I feel we should
go with group clog approach now as that has been tested and reviewed
multiple times and in future if we find that other approach is giving
substantial gain, then we can anyway change it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. Use group updates when setting transaction status in clog.

  2. Improve 64bit atomics support.

  3. Add ProcArrayGroupUpdate wait event.

  4. Make the different Unix-y semaphore implementations ABI-compatible.

  5. Fix broken ALTER INDEX documentation

  6. Code and docs review for commit 3187d6de0e5a9e805b27c48437897e8c39071d45.

  7. Partition the freelist for shared dynahash tables.

  8. Correct StartupSUBTRANS for page wraparound

  9. Make idle backends exit if the postmaster dies.

  10. contrib/sslinfo: add ssl_extension_info SRF

  11. Reduce ProcArrayLock contention by removing backends in batches.

  12. Fix `make installcheck` for serializable transactions.

  13. Lockless StrategyGetBuffer clock sweep hot path.

  14. Reduce sinval synchronization overhead.