How To Dev

Introduction The IN clause is usually used in two main cases: Literal Values : When you already know the exact values to filter and the number of elements is small (from a few elements to a few dozen elements). Note that when parsing, Postgres will treat each item in Literal Values as a single node to execute the Parse Tree, so if the number of items is too large, it will consume a lot of RAM and CPU to process By the time planning is executed, the Query Planner will have to traverse this Tree to process, so you should be careful not to query with too many Literal Values as it will significantly affect performance It can be rewritten with EXISTS but it will make the query more complex, so if using Literal Values , it is best to use IN to keep the query simple and easy to understand An example of usage is filtering out orders with statuses like processing or completed . Dynamic List : When the filter list depends on the data of another table. In most cases, it can be replaced by usin...

Introduction When joining multiple tables together (such as 3 tables or more), PostgreSQL never joins all tables at the same time, but at any single point in time, it can only join 2 datasets. Suppose you need to join multiple tables, the process of bridging steps will be performed as follows First, Postgres will select 2 tables to join together to create an Intermediate Result Postgres will treat the Intermediate Result as a completely new table and will use it to join with the next table to create the next Intermediate Result This process repeats over and over until all tables have been joined. Algorithms used When joining multiple tables, Postgres still uses algorithms like Nested Loop Join, Hash Join and Merge Join But corresponding to each dataset and the index of the tables, Postgres will choose different algorithms when joining rather than fixing a single algorithm For example, when joining 4 tables A, B, C and D together Suppose table A is small with about 100 rows joining with...

Introduction In this article, we will learn about Merge Join. How It Works Simply put, how Merge Join works is like sorting two lists in ascending order first, then placing them side by side for comparison. Assuming we need to compare the id column of two tables, A and B, the specific process is as follows: Step 1: Sort Phase PostgreSQL must ensure that both lists are already sorted by the order of the join column (for example, from smallest to largest). If the two tables are already sorted, such as when the join column is a Primary Key or has an Index, Postgres will skip this step and jump to step 2. Step 2: Merge Phase PostgreSQL will place two pointers starting from the first row of the two tables and begin comparing: If the results on both sides are equal: Return the result, then move the pointer in table B to the next row to continue checking (since data in a column can be duplicated). If the id in table A is smaller: Move the table A pointer to the next row. If the id in table A ...