Analyzing Scans in PostgreSQL
Understand the different types of Scans in PostgreSQL and why the query planner chooses them in different situations.
Understand the different types of Scans in PostgreSQL and why the query planner chooses them in different situations.
MySQL's Query Cache is incredibly versatile. It’s usually able to store a wide variety of values and return them from the memory (rather than the disk) to improve query execution times. This guide will explore the usages and limitations of query caching.
Slow query performance is a huge thing—so much so that modern database performance optimization techniques are in large part targeted at mitigating slow queries. Surprising? We think not.
Indexes are frequent friends for SELECT queries; however, if we want to use indexes, we must ensure that our database instances use them first. Indexes that are not utilized by our database instances are useless – they waste space and make INSERT, UPDATE, and DELETE queries slower.
If you have found yourself in the MySQL world (at least for a little while), chances are that you have probably heard about the usage of EXPLAIN. In the MySQL world, this keyword is everywhere.
Some MySQL engineers might call them the cornerstone of improving performance in MySQL: indexes are data structures that are frequently used to quickly find rows matching a given query.
During my work tenure, I got a chance to work with MySQL databases with as many as 700 million rows. This post will emphasize how to index and optimize your MySQL queries for indexes.
As developers, we are aware of various best practices for SQL query optimization. While a few of these are specific to individual relational database management systems (RDBMSs), most can apply to virtually any database.
A PostgreSQL database health dashboard allows us to monitor the database in real-time and helps us to more fully understand some features which are unique to PostgreSQL.