Book Image

PostgreSQL 10 High Performance - Third Edition

By : Enrico Pirozzi
Book Image

PostgreSQL 10 High Performance - Third Edition

By: Enrico Pirozzi

Overview of this book

PostgreSQL database servers have a common set of problems that they encounter as their usage gets heavier and requirements get more demanding. Peek into the future of your PostgreSQL 10 database's problems today. Know the warning signs to look for and how to avoid the most common issues before they even happen. Surprisingly, most PostgreSQL database applications evolve in the same way—choose the right hardware, tune the operating system and server memory use, optimize queries against the database and CPUs with the right indexes, and monitor every layer, from hardware to queries, using tools from inside and outside PostgreSQL. Also, using monitoring insight, PostgreSQL database applications continuously rework the design and configuration. On reaching the limits of a single server, they break things up; connection pooling, caching, partitioning, replication, and parallel queries can all help handle increasing database workloads. By the end of this book, you will have all the knowledge you need to design, run, and manage your PostgreSQL solution while ensuring high performance and high availability
Table of Contents (18 chapters)

Index statistics

There are a parallel set of statistics to the table ones that break down activity for each individual index. pg_stat_user_indexes also has system/all versions available, and it gives information about how many index scans were done and the rows returned by them.

The naming of the fields in this view are more complicated to distinguish between though. Two fields that look similar are subtly different:

  • idx_tup_read: Number of index entries returned by index scans.
  • idx_tup_fetch: Number of live table rows fetched by simple index scans using that index. This number will often be a bit smaller than the idx_tup_read value because it won't include dead or not yet committed rows in its count. In addition, the use of simple here means that the index access was not a bitmap index scan. When those execute, there are at least two indexes involved. That makes it impossible...