Percona finds that MySQL on ZFS is now on par with ext4 performance-wise for their test use case.

The author analyzes a real-world Postgres performance issue related to the GIN index fast update technique analyzed.

This is an interesting write-up of a PostgreSQL performance issue.

In this post, the author takes a look at different MySQL workloads on NVME drives.

Percona compared the price-performance of PostgreSQL on x86 and ARM AWS EC2 instances.

In this blog post, Chris Siebenmann explains the consequences of not tuning ZFS to match your database's requirements.

This blog post explains MySQL memory instrumentation with Performance Schema and how to use custom queries with the MySQL exporter.

1. Applying the correct troubleshooting steps to your problems is crucial:
   a) Understand what resources have been saturated.
   b) Understand what if anything is causing an error.
   c) From there you can divert into the areas that are related to that resource and start to narrow down the issue.
   d) Tackle the problems bit by bit.
2. Having the right tools for the job key for success. PMM is a great example of a tool that can help you quickly identify, drill in, and fix bottlenecks.
3. Have realistic load tests. In this case, they had tested the new release on a concurrency level that was not like their production
4. By identifying the culprit query we were able to:
   a.) Drop average query time from 20s to 661ms
   b.) Increase QPS by 2x
   c.) Reduce the usage of CPU to 1/4 of its level prior to our intervention

Conclusions:

1. Network performance and utilization will affect the general application throughput.
2. Check if you are hitting network bandwidth limits
3. Protocol compression can improve the results if you are limited by network bandwidth, but also can make things worse if you are not
4. SSL encryption has some penalty (~10%) with a low amount of threads, but it does not scale for high concurrency workloads.

PostgreSQL is emerging as the standard destination for database migrations from proprietary databases. As a consequence, there is an increase in demand for database side code migration and associated performance troubleshooting. One might be able to trace the latency to a plsql function, but explaining what happens within a function could be a difficult question. Things get messier when you know the function call is taking time, but within that function there are calls to other functions as part of its body. It is a very challenging question to identify which line inside a function—or block of code—is causing the slowness. In order to answer such questions, we need to know how much time an execution spends on each line or block of code. The plprofiler project provides great tooling and extensions to address such questions.