Migrate PostgreSQL roadmap to our editor

5 months ago · b48f81d98d
parent f179033dd3
commit b48f81d98d
206 changed files with 8359 additions and 13589 deletions
--- a/src/data/roadmaps/postgresql-dba/content/100-roadmap-note.md
+++ b/src/data/roadmaps/postgresql-dba/content/100-roadmap-note.md
@ -1,10 +0,0 @@
 # Important Note
 If you are just a beginner trying to learn PostgreSQL, don't get discouraged by looking at the content of this roadmap. It is designed for people who are already familiar with PostgreSQL. Just learn some basics of PostgreSQL and then come back to this roadmap when you are ready to skill up and learn more advanced topics.
 Also, note that the roadmap topics contain some introductory content that is meant to help you get started with the topic. You may have to do some research on your own to learn more about the topic.
 If you are a beginner, you can start with the following resources:
 - [@article@PostgreSQL Tutorial](https://www.postgresqltutorial.com/)
 - [@article@PostgreSQL Exercises](https://pgexercises.com/)
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/index.md
@ -1,75 +0,0 @@
 # DDL Queries
 DDL stands for Data Definition Language. DDL queries are a subset of SQL queries that are responsible for defining and managing the structure of your database, such as creating, altering, and deleting tables, constraints, and indexes. In this section, we will discuss the basic DDL statements: `CREATE`, `ALTER`, and `DROP`.
 ## CREATE
 `CREATE` is used to create a new database object (e.g., table, index, sequence, etc.). The syntax for creating a table in PostgreSQL is as follows:
 ```sql
 CREATE TABLE table_name (
   column1 data_type constraints,
   column2 data_type constraints,
   ...
 );
 ```
 An example of creating a table named `employees` with columns `id`, `first_name`, and `last_name` would be:
 ```sql
 CREATE TABLE employees (
   id SERIAL PRIMARY KEY,
   first_name VARCHAR(255) NOT NULL,
   last_name VARCHAR(255) NOT NULL
 );
 ```
 ## ALTER
 `ALTER` is used to modify an existing database object, such as adding or removing columns, changing data types, or adding constraints. The basic syntax for altering a table in PostgreSQL is:
 ```sql
 ALTER TABLE table_name
 ACTION column_name data_type constraints;
 ```
 Some examples of altering a table include:
 - Adding a column:
  ```sql
  ALTER TABLE employees
  ADD COLUMN email VARCHAR(255) UNIQUE;
  ```
 - Modifying a column's data type:
  ```sql
  ALTER TABLE employees
  ALTER COLUMN email SET DATA TYPE TEXT;
  ```
 - Removing a constraint:
  ```sql
  ALTER TABLE employees
  DROP CONSTRAINT employees_email_key;
  ```
 ## DROP
 `DROP` is used to permanently delete a database object. The syntax for dropping a table in PostgreSQL is:
 ```sql
 DROP TABLE table_name;
 ```
 To delete the `employees` table created earlier:
 ```sql
 DROP TABLE employees;
 ```
 _Note_: Be cautious when using the `DROP` statement, as all data and schema associated with the deleted object will be lost permanently.
 In this section, we have covered the basic DDL queries in PostgreSQL, which allow you to create, modify, and delete database objects. Remember to always test your DDL statements before applying them to the production environment to avoid unintended consequences.
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/index.md
@ -1,86 +0,0 @@
 # DML Queries in PostgreSQL
 In this section, we will be discussing Data Manipulation Language (DML) queries in PostgreSQL. DML queries are used to manage and modify data in tables. As an integral part of SQL, they allow us to perform various operations such as inserting, updating, and retrieving data. The main DML queries are as follows:
 ## INSERT
 The `INSERT` statement is used to add new rows to a table. The basic syntax for the `INSERT` command is:
 ```
 INSERT INTO table_name (column1, column2,...)
 VALUES (value1, value2,...);
 ```
 For example, to insert a new row into a table named `employees` with columns `employee_id`, `first_name`, and `last_name`, we would use:
 ```
 INSERT INTO employees (employee_id, first_name, last_name)
 VALUES (1, 'John', 'Doe');
 ```
 ## UPDATE
 The `UPDATE` statement is used to modify existing data in a table. The basic syntax for the `UPDATE` command is:
 ```
 UPDATE table_name
 SET column1 = value1, column2 = value2,...
 WHERE condition;
 ```
 For example, to update the `first_name` of an employee with an `employee_id` of 1, we would use:
 ```
 UPDATE employees
 SET first_name = 'Jane'
 WHERE employee_id = 1;
 ```
 Be cautious with `UPDATE` statements, as not specifying a `WHERE` condition might result in updating all rows in the table.
 ## DELETE
 The `DELETE` statement removes one or more rows from a table. The basic syntax for the `DELETE` command is:
 ```
 DELETE FROM table_name
 WHERE condition;
 ```
 For example, to remove an employee row with an `employee_id` of 1, we would use:
 ```
 DELETE FROM employees
 WHERE employee_id = 1;
 ```
 Similar to the `UPDATE` statement, not specifying a `WHERE` condition in `DELETE` might result in removing all rows from the table.
 ## SELECT
 The `SELECT` statement is used to retrieve data from one or more tables. The basic syntax for the `SELECT` command is:
 ```
 SELECT column1, column2,...
 FROM table_name
 WHERE condition;
 ```
 For example, to retrieve the first name and last name of all employees, we would use:
 ```
 SELECT first_name, last_name
 FROM employees;
 ```
 To retrieve the first name and last name of employees with an `employee_id` greater than 10, we would use:
 ```
 SELECT first_name, last_name
 FROM employees
 WHERE employee_id > 10;
 ```
 You can also use various clauses such as `GROUP BY`, `HAVING`, `ORDER BY`, and `LIMIT` to further refine your `SELECT` queries.
 In summary, DML queries help you interact with the data stored in your PostgreSQL database. As you master these basic operations, you'll be able to effectively manage and modify your data according to your application's needs.
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/index.md
@ -1,98 +0,0 @@
 # Advanced SQL Topics
 In this section, we will explore some advanced SQL concepts that will help you unlock the full potential of PostgreSQL. These topics are essential for tasks such as data analysis, optimizations, and dealing with complex problems.
 ## Window Functions
 Window functions allow you to perform calculations across a set of rows related to the current row while retrieving data. They can help you find rankings, cumulative sums, and moving averages.
 ```sql
 SELECT user_id, total_purchase, RANK() OVER (ORDER BY total_purchase DESC) as rank
 FROM users;
 ```
 This query ranks `users` by their `total_purchase` value.
 ## Common Table Expressions (CTEs)
 CTEs let you create temporary tables that exist only during the execution of a single query. They are useful when dealing with complex and large queries, as they can help in breaking down the query into smaller parts.
 ```sql
 WITH top_users AS (
  SELECT user_id
  FROM users
  ORDER BY total_purchase DESC
  LIMIT 10
 )
 SELECT * FROM top_users;
 ```
 This query uses a CTE to first find the top 10 users by total_purchase, and then retrieves their details in the main query.
 ## Recursive CTEs
 A recursive CTE is a regular common table expression that has a subquery which refers to its own name. They are useful when you need to extract nested or hierarchical data.
 ```sql
 WITH RECURSIVE categories_tree (id, parent_id) AS (
  SELECT id, parent_id
  FROM categories
  WHERE parent_id IS NULL
  UNION ALL
  SELECT c.id, c.parent_id
  FROM categories c
  JOIN categories_tree ct ON c.parent_id = ct.id
 )
 SELECT * FROM categories_tree;
 ```
 This query retrieves the entire hierarchy of categories using a recursive CTE.
 ## JSON Functions
 PostgreSQL has support for JSON and JSONB data types. JSON functions enable you to create, manipulate, and query JSON data directly in your SQL queries.
 ```sql
 SELECT json_build_object('name', name, 'age', age) as json_data
 FROM users;
 ```
 This query creates a JSON object for each user, containing their name and age.
 ## Array Functions
 PostgreSQL allows you to work with arrays and perform operations on them, such as array decomposition, slicing, and concatenation.
 ```sql
 SELECT array_agg(user_id)
 FROM users
 GROUP BY city;
 ```
 This query returns an array of user IDs for each city.
 ## Full-text Search
 PostgreSQL offers powerful full-text search capabilities, which enable you to search through large bodies of text efficiently.
 ```sql
 SELECT title
 FROM articles
 WHERE to_tsvector('english', title) @@ to_tsquery('english', 'PostgreSQL');
 ```
 This query retrieves articles with the title containing 'PostgreSQL'.
 ## Performance Optimization
 Understand indexing, query planning, and execution, as well as implementing various optimizations to make your queries run faster, is essential for handling large data sets or high-traffic applications.
 ```sql
 CREATE INDEX idx_users_city ON users (city);
 ```
 This command creates an index on the `city` column of the `users` table to speed up queries involving that column.
 These advanced topics can help you become a highly skilled PostgreSQL user and tackle complex real-world problems effectively. As you become more comfortable with these advanced concepts, you will unleash the full power of SQL and PostgreSQL.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/index.md
@ -1,71 +0,0 @@
 # Replication in PostgreSQL
 Replication is an essential aspect of PostgreSQL infrastructure skills as it plays a crucial role in ensuring data redundancy and high availability. Replication is the process of copying data changes made on one database (the primary) to another database (the replica). This sync happens in real-time or as close to it as possible. Replication is highly useful in disaster recovery, read-scaling, and backup scenarios.
 ## Types of Replication
 There are two main types of replication in PostgreSQL:
 - **Physical Replication**: In physical replication, the changes at the block level (i.e., binary data) of the primary database are copied to the replica. The replica is an identical copy of the primary, including the structure and data.
 - **Logical Replication**: In logical replication, a specific set of changes (INSERT, UPDATE, DELETE or TRUNCATE) at the row level of the primary database are replicated to the replica. It provides more flexibility as it allows replicating changes to specific tables, or even selective columns, which may differ in their structure compared to the primary.
 ## Replication Methods
 PostgreSQL offers various replication methods, including:
 - **Streaming Replication**: This method uses primary's write-ahead logs (WALs) to keep the replica up-to-date. WALs consist of every change made to the primary's data. The primary sends WALs to the replica, which applies the changes to stay in sync. You can configure streaming replication as synchronous or asynchronous.
 - **Logical Decoding**: This method is responsible for generating a sequence of logical changes by decoding the primary's WALs. Logical decoding can be used in logical replication for capturing specific data changes and replicating them to the replica.
 - **Trigger-Based Replication**: This method involves using triggers on the primary database to record changes into specific tables. Third-party tools like Slony and Londiste use trigger-based replication.
 ## Setting up Replication
 To set up replication in PostgreSQL, you will need to follow these steps:
 - **Primary Server Configuration**: Set the following parameters in the `postgresql.conf` on the primary server.
    ```
    wal_level = 'replica'
    max_wal_senders = 3
    max_replication_slots = 3
    wal_keep_segments = 64
    listen_addresses = '*'
    ```
 - **Replica Server Configuration**: Set the following parameters in the `postgresql.conf` on the replica server.
    ```
    hot_standby = on
    ```
 - **Authentication**: Add an entry in the `pg_hba.conf` file on the primary server to allow the replica to connect.
    ```
    host replication <replica_user> <replica_ip>/32 md5
    ```
 - **Create Replication User**: Create a replication user on the primary server with the REPLICATION attribute.
    ```
    CREATE USER <replica_user> WITH REPLICATION ENCRYPTED PASSWORD '<password>';
    ```
 - **Create Base Backup**: Create a base backup of the primary server using `pg_basebackup` tool, specifying the destination directory (`<destination>`) on the replica server.
    ```
    pg_basebackup -h <primary_ip> -D <destination> -U <replica_user> -vP --wal-method=fetch
    ```
 - **Configure Recovery**: On the replica server, create a `recovery.conf` file in the data directory to configure it to connect to the primary server for streaming replication.
    ```
    standby_mode = 'on'
    primary_conninfo = 'host=<primary_ip> port=5432 user=<replica_user> password=<password>'
    trigger_file = '/tmp/replica_trigger' # This can be any custom path of your choice
    ```
 - **Start Replica**: Start the replica server, and it will begin syncing the data from the primary server.
 ## Failover and Monitoring
 You can monitor the replication status using the `pg_stat_replication` view, which contains information about the replication sessions and progress.
 In case of a primary server failure, you can switch to the replica server by creating a trigger file, as specified in the `recovery.conf`. The replica server will promote to a primary server, accepting read and write connections.
 Remember to thoroughly understand replication in PostgreSQL, as it is a critical aspect of maintaining a successful database infrastructure.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/101-connection-pooling/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/101-connection-pooling/index.md
@ -1,23 +0,0 @@
 # Connection Pooling
 Connection pooling is an important aspect of PostgreSQL Infrastructure skills that you need to understand in order to maintain a healthy and efficient database system. Connection pooling refers to the method of reusing database connections, rather than establishing a new connection each time a client requests access to the database. Below, we will discuss the concept of connection pooling and its benefits, and we will explore some popular connection pooling tools available for PostgreSQL.
 ## Concept and Benefits
 When multiple clients or applications require access to a PostgreSQL database, it can lead to a large number of connections being created, which could significantly impact the performance and stability of the system. Connection pooling helps mitigate this issue by:
 - Reducing the overhead of establishing new connections: Establishing a new connection is resource-intensive and can take a long time. Reusing existing connections reduces this overhead.
 - Limiting the number of active connections: Connection pools typically limit the total number of connections that can be created, which can help prevent connection overloads and improve database server stability.
 - Balancing the load across connections: Connection pools can efficiently distribute the load among different connections, helping to optimize system performance.
 ## Connection Pooling Tools for PostgreSQL
 There are several popular connection pooling tools available for PostgreSQL, each with its own set of features and functionality. Some well-known options include:
 - **PgBouncer**: PgBouncer is a lightweight and widely-used connection pooler for PostgreSQL. It offers features like session pooling, transaction pooling, and statement pooling, allowing you to customize the level of connection reuse according to your requirements.
 - **Pgpool-II**: Pgpool-II is more than just a connection pooler; it also offers advanced features like load balancing, automatic failover, and parallel query execution. It is especially suitable for large-scale, high-availability PostgreSQL deployments.
 - **Odyssey**: Odyssey is a scalable, high-performance connection pooler and proxy for PostgreSQL. It offers features like connection routing, TLS support, and load balancing, making it a great choice for complex and secure PostgreSQL setups.
 ## Conclusion
 Understanding connection pooling and utilizing connection poolers effectively is crucial for maintaining an efficient and reliable PostgreSQL database system. By familiarizing yourself with the different pooling tools available, you can choose the one that best suits your infrastructure needs, and optimize your database performance while minimizing resource usage.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/index.md
@ -1,54 +0,0 @@
 # Backup Recovery Tools in PostgreSQL
 Backup recovery tools are essential to ensure data safety and minimize data loss in the event of hardware and/or software failure or any other disaster. In this topic, we will discuss the most commonly used backup recovery tools in PostgreSQL.
 ## pg_dump and pg_restore
 `pg_dump` is a utility provided by PostgreSQL to create a backup of a single database. It generates a SQL file or a custom-format archive that contains the data and schema of the specified database. The command syntax is as follows:
 ```bash
 pg_dump --host <hostname> --port <port> --username <username> --password <password> --file <output-file> <database>
 ```
 After creating a backup with `pg_dump`, you can use the `pg_restore` tool to restore the database from the generated SQL file or custom-format archive. The command syntax is as follows:
 ```bash
 pg_restore --host <hostname> --port <port> --username <username> --password <password> --dbname <database> <input-file>
 ```
 ## pg_basebackup
 `pg_basebackup` is a utility that creates a binary copy (base backup) of an entire PostgreSQL cluster, including all data files, tablespaces, and configuration files. The base backup can be used as a starting point for setting up a new replica or to restore the cluster during a disaster. The command syntax is as follows:
 ```bash
 pg_basebackup --host <hostname> --port <port> --username <username> --password <password> --directory <output-directory> --progress --verbose
 ```
 The `--progress` flag is optional and displays a progress report, while the `--verbose` flag increases information messages.
 ## Continuous Archiving and Point-in-Time Recovery (PITR)
 Apart from backing up the entire database, PostgreSQL also allows continuous archiving of the write-ahead log (WAL) files. This technique, combined with the base backup, helps in recovering data up to a specific point in time.
 To enable continuous archiving, you need to modify the `postgresql.conf` file and set the `wal_level` to `replica`, `archive_mode` to `on`, and configure `archive_command`. For example:
 ```
 wal_level = replica
 archive_mode = on
 archive_command = 'cp %p /path/to/archive/%f'
 ```
 The `archive_command` is a shell command used for archiving the WAL files, and `%p` and `%f` are placeholders for the file path and file name, respectively.
 Point-in-Time Recovery (PITR) can be performed by configuring the `recovery.conf` file in the data directory of the PostgreSQL instance. It includes setting the `restore_command`, which is a shell command for restoring WAL files. An example configuration:
 ```
 restore_command = 'cp /path/to/archive/%f %p'
 recovery_target_time = '2021-12-31 23:59:59'
 ```
 In the configuration above, the `recovery_target_time` specifies the exact time up to which the database should be recovered.
 ## Conclusion
 In this topic, we have discussed the most commonly used backup recovery tools in PostgreSQL such as `pg_dump`, `pg_restore`, `pg_basebackup`, and continuous archiving with PITR. These tools help to ensure data safety in PostgreSQL by providing various backup and recovery options. It is crucial to have a proper backup strategy in place to handle unforeseen circumstances and ensure minimal data loss.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/103-upgrade-procedures/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/103-upgrade-procedures/index.md
@ -1,67 +0,0 @@
 # Upgrade Procedures in PostgreSQL
 Upgrading a PostgreSQL database is an essential task that developers and administrators need to perform periodically. Knowing the most effective and secure upgrade procedures helps you minimize downtime and maintain the stability of your applications. In this section, we will discuss various methods for upgrading PostgreSQL and the pros and cons of each method.
 ## In-Place Upgrades
 In-place upgrades involve updating the PostgreSQL package (RPM or DEB packages, for example) to the newest version. The PostgreSQL service is then restarted to run the upgraded version.
 **Pros:**
 - Easy to perform
 - Minimal effort and planning required
 **Cons:**
 - Longer downtime during the upgrade process
 - Difficult to revert to the older version if problems occur
 ## Logical Upgrades
 Logical upgrade procedures involve exporting and importing data as SQL files or using tools like `pg_dump` and `pg_restore`. This method involves creating a new instance of the PostgreSQL server, importing the dumped data, and then repointing applications to the new instance.
 **Pros:**
 - Allows for data validation before switching applications to new instances
 - Easier to revert back to the old instance in case of issues
 **Cons:**
 - Time-consuming, especially for large databases
 - May require extra storage space for exported data files
 ## Physical Upgrades
 Physical upgrades involve copying the entire data directory over to the new PostgreSQL instance. This method requires that the new version of PostgreSQL can use the existing format of the data directory. In this process, you would stop the PostgreSQL service, copy the data directory, and then start the service on the new instance.
 **Pros:**
 - Minimal downtime compared to logical upgrades
 - Easier process for large databases
 **Cons:**
 - Higher risk of data corruption
 - Compatibility issues may arise with new PostgreSQL versions
 ## Pg_upgrade
 Pg_upgrade (formerly known as `pg_migrator`) is a tool provided by PostgreSQL that allows for faster, in-place upgrading by creating hard links instead of copying data files. This greatly reduces downtime and storage requirements.
 **Pros:**
 - Faster than other methods
 - No need for additional storage space
 - Minimal downtime
 **Cons:**
 - Can be challenging to recover from errors
 - Must have compatibility at the disk level between source and target clusters
 ## Replication-based Upgrades
 Tools like `pglogical`, `pglogical_slot` or built-in replication can be used for upgrading PostgreSQL using replication. The fundamental idea is that while the old version is running, a replica instance is created with the new PostgreSQL version. Once the replication process is complete, the application can be repointed to the new instance.
 **Pros:**
 - Minimal downtime
 - Can validate and test new instance before switching over
 - Easier to revert back to an older instance if needed
 **Cons:**
 - Time-consuming for initial setup and replication
 - Requires additional hardware resources for replica instances
 In summary, the ideal upgrade strategy for your PostgreSQL infrastructure would depend on various factors like database size, downtime tolerance, and resource availability. It's recommended to have a well-planned and tested upgrade strategy in place to ensure smooth and successful upgrades.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/104-cluster-management/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/104-cluster-management/index.md
@ -1,52 +0,0 @@
 # Cluster Management
 Cluster management is a crucial aspect of PostgreSQL infrastructure, as it ensures the efficient and reliable operation of the database system. In this section, we will discuss some of the key aspects of cluster management in PostgreSQL, covering topics like creating and configuring clusters, monitoring and maintaining high availability, and disaster recovery best practices.
 ## Creating and Configuring Clusters
 - **Creating a Cluster**: PostgreSQL clusters can be created using the `initdb` command or using the `pg_createcluster` utility (Debian-based distributions). It is important to properly define settings like cluster data directory, port number, and locale during creation.
  ```
  initdb -D /path/to/your/data/directory
  ```
 - **Configuring a Cluster**: The main configuration file in a PostgreSQL cluster is the `postgresql.conf`, where various parameters like listen address, port, authentication, and performance tuning can be defined. Remember to restart PostgreSQL after making changes.
  ```
  listen_addresses = 'localhost'  # or '*' for all interfaces
  port = 5432
  max_connections = 100
  ```
 ## Monitoring and Maintaining High Availability
 To ensure high availability and efficient utilization of resources in a PostgreSQL cluster, monitoring and maintenance practices are vital. Here are a few key aspects:
 - **Load Balancing**: Employ load balancers like PgPool-II or HAProxy to distribute read queries across multiple read replicas, helping reduce the load on the primary server.
 - **Connection Pooling**: Connection pooling solutions like PgBouncer can help minimize connection overhead, improving performance and preventing connection exhaustion.
 - **Performance Monitoring**: Keep track of key metrics like disk I/O, connections, CPU usage, and index usage, using monitoring tools like pg_stat_statements, pgBadger, or Datadog.
 - **Failover and Switchover**: Implement mechanisms to automatically promote a read replica to primary in case of primary server failure.
 ## Disaster Recovery
 A robust disaster recovery plan is essential for PostgreSQL cluster management. Here are some best practices:
 - **Backup**: Perform regular backups of your PostgreSQL cluster, including full database dumps using `pg_dump` or `pg_dumpall`, and continuous archiving with Write Ahead Logs (WAL).
  ```
  pg_dump dbname > backup.sql
  ```
 - **Point-in-Time Recovery (PITR)**: Configure your system for PITR, allowing you to recover your database to a specific time or transaction using WAL archives.
  ```
  recovery_target_time = '2021-08-02 14:30:00'
  restore_command = 'cp /path/to/archive/%f %p'
  ```
 - **Geo-Redundancy**: Deploy read replicas in separate geographic locations or cloud regions to protect against data loss due to regional disasters.
 By understanding and mastering these aspects of cluster management, you can ensure that your PostgreSQL infrastructure remains performant, available, and secure at all times.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/index.md
@ -1,73 +0,0 @@
 # Kubernetes Deployment
 Kubernetes is an open-source container orchestrator that automates the deployment, scaling, and management of containerized applications in a clustered environment. Kubernetes deployments are a higher-level abstraction of managing the applications' desired state, including the number of replicas and the application version. The main advantage of using Kubernetes is that it provides automated rollouts, easy scaling, and management of your applications.
 ## Kubernetes Deployment Components
 A Kubernetes deployment consists of several key components:
 - **Deployment Object** - Defines the desired state of the application, such as the number of replicas, the version of the application, and the environment.
 - **ReplicaSet** - Ensures that the desired number of replicas of the application is always running.
 - **Pod** - A group of one or more containers that share the same network and are deployed on the same machine.
 ## Deploying a PostgreSQL Application on Kubernetes
 You can deploy a PostgreSQL application on Kubernetes by following these steps:
 - **Create a Deployment YAML file** - This file will define the deployment specification of your PostgreSQL application. It should specify the PostgreSQL container image, the number of replicas, and any other required settings like environment variables, secrets, and volumes:
  ```
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: postgresql
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: postgresql
    template:
      metadata:
        labels:
          app: postgresql
      spec:
        containers:
        - name: postgres
          image: postgres:latest
          env:
          - name: POSTGRES_DB
            value: mydb
          - name: POSTGRES_USER
            valueFrom:
              secretKeyRef:
                name: postgres-secret
                key: username
          - name: POSTGRES_PASSWORD
            valueFrom:
              secretKeyRef:
                name: postgres-secret
                key: password
          ports:
          - containerPort: 5432
            name: postgres
          volumeMounts:
          - name: postgres-data
            mountPath: /var/lib/postgresql/data
        volumes:
        - name: postgres-data
          persistentVolumeClaim:
            claimName: postgres-pvc
  ```
 - **Create and apply the deployment in Kubernetes** - Run `kubectl apply -f deployment.yaml` to create the deployment in your Kubernetes cluster.
 - **Expose the PostgreSQL service** - To access your PostgreSQL application from outside the Kubernetes cluster, you can expose it as a service using `kubectl expose` command or a YAML file.
 - **Scale your deployment** - You can easily scale your PostgreSQL application by changing the number of replicas in the deployment file, then updating it using `kubectl apply -f deployment.yaml`.
 By following these steps, you can successfully deploy and manage a PostgreSQL application using the Kubernetes deployment system.
 - [@article@Run PostgreSQL. The Kubernetes way](https://cloudnative-pg.io/)
 - [@feed@Explore top posts about Kubernetes](https://app.daily.dev/tags/kubernetes?ref=roadmapsh)
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/index.md
@ -1,57 +0,0 @@
 # Monitoring in PostgreSQL
 Monitoring is an essential aspect of maintaining a healthy and well-performing PostgreSQL database infrastructure. It helps to ensure optimal performance and allows for early detection of potential issues before they lead to serious problems or outages. In this section, we'll discuss the basics of PostgreSQL monitoring, key performance indicators (KPIs), helpful monitoring tools, and best practices.
 ## Why Monitoring is Important
 - **Optimizes database performance**: Regular monitoring helps detect issues in the PostgreSQL infrastructure that can impact performance, such as resource contention, inefficient queries, or improperly sized hardware.
 - **Ensures data integrity**: Monitoring can help detect database errors or corruption, allowing you to address the problem before it causes data loss or affects other parts of your application.
 - **Prevents downtime**: By identifying potential issues before they become critical, monitoring can help prevent system outages and minimize downtime.
 - **Capacity planning**: Monitoring can provide insights into resource utilization, enabling you to make informed decisions about scaling and resource allocation.
 ## Key Performance Indicators (KPIs)
 Some of the KPIs you should track for PostgreSQL monitoring include:
 - **Queries per second**: The number of queries executed by the PostgreSQL server per second. High query rates can indicate performance bottlenecks or inefficient queries.
 - **Connections**: The number of active connections to the PostgreSQL server. Connection spikes can indicate issues with connection pooling or application performance.
 - **CPU, Memory, and Disk utilization**: Monitor the CPU, memory, and disk usage of the PostgreSQL server to identify potential resource bottlenecks.
 - **Cache hit ratio**: The ratio of database requests (reads/writes) served from the cache compared to those served by reading/writing directly to disk. High cache hit ratios generally indicate good memory utilization and efficient queries.
 - **Slow queries**: The number of queries taking longer than a specified threshold to execute. Identifying slow queries can help target specific areas for performance optimization.
 - **Replication lag**: The time difference between the master database and its replicas, which should be minimal to ensure data consistency.
 ## Monitoring Tools
 Several tools are available to help you with PostgreSQL monitoring:
 - **pg_stat_statements**: A built-in PostgreSQL extension that provides insights into query performance and resource utilization.
 - **pgBadger**: A popular open-source log analyzer that provides detailed reports on query performance and error analysis.
 - **Pgpool-II**: A middleware solution that provides load balancing, connection pooling, and monitoring features for PostgreSQL.
 - **Check_postgres**: A script for monitoring various aspects of a PostgreSQL database, useful for integrating with monitoring solutions like Nagios or Zabbix.
 - **Datadog, New Relic, and other APM tools**: These third-party services provide powerful monitoring, alerting, and visualization capabilities for PostgreSQL databases.
 ## Best Practices
 - **Set up alerts**: Configure alerting based on KPI thresholds so you can quickly address potential issues before they become critical.
 - **Monitor logs**: Regularly review PostgreSQL logs to identify error messages, slow queries, or other issues impacting performance or stability.
 - **Monitor replication**: Keep a close eye on replication lag and the health of your replicas to ensure data consistency and high availability.
 - **Establish baselines**: Establish performance and resource baselines to help identify deviations from normal behavior and to compare before/after infrastructure changes.
 - **Test and optimize**: Continuously test and optimize your queries, schemas, and configurations to maximize performance.
 By following these guidelines and maintaining a strong monitoring strategy, you can ensure a healthy, high-performing PostgreSQL infrastructure.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/index.md
@ -1,24 +0,0 @@
 # Load Balancing in PostgreSQL
 Load balancing is an essential technique for optimizing databases and applications by distributing workloads evenly across multiple resources. In the context of PostgreSQL, load balancing refers to spreading user requests and transactions across multiple database servers to ensure high availability, fault tolerance, and optimal performance. This section provides a brief overview of load balancing in PostgreSQL and its importance in enhancing infrastructure.
 ## Key Benefits of Load Balancing
 * **High Availability**: Load balancing prevents a single point of failure by distributing queries across multiple servers, ensuring that if one server goes down, the remaining servers can still handle requests.
 * **Scalability**: As your application grows, load balancing allows you to add more servers to your infrastructure to handle increasing traffic and processing demands.
 * **Fault Tolerance**: Load balancing enhances fault tolerance in your PostgreSQL infrastructure as it automatically reroutes traffic to healthy servers if any server encounters issues or fails.
 * **Improved Performance**: Distributing queries and connections across multiple servers allows for more efficient utilization of system resources, resulting in better performance and faster response times.
 ## Load Balancing Techniques in PostgreSQL
 There are several techniques and tools available to implement load balancing in a PostgreSQL infrastructure. Here are a few common methods:
 - **Connection Pooling**: Connection pooling consists of managing and controlling the number of database connections, allowing for the efficient distribution of connections across servers. A popular PostgreSQL connection pooling tool is PgBouncer.
 - **Read/Write Split**: This technique involves separating read queries (SELECT) from write queries (INSERT, UPDATE, DELETE) and distributing them across different servers. This ensures that read-heavy workloads do not affect the performance of write operations. PgPool-II is a popular PostgreSQL middleware that can perform read/write splitting.
 - **Load Balancing with Proxy or Middleware**: Another common approach is using a reverse proxy or middleware that sits between your application and your PostgreSQL servers. This method allows you to distribute queries across multiple servers based on various algorithms, such as round-robin, least connection, or resource-based. Some popular choices include HAProxy and PgPool-II.
 ## Conclusion
 Implementing load balancing in your PostgreSQL infrastructure is crucial for maintaining high availability, performance, and fault tolerance. By understanding the benefits and techniques of load balancing, you can make informed decisions on how to optimize your PostgreSQL infrastructure for your specific needs.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/108-anonymization/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/108-anonymization/index.md
@ -1,29 +0,0 @@
 # Anonymization
 Anonymization is the process of protecting sensitive and personally identifiable information (PII) from being exposed, by replacing or changing the data in a way that it becomes impossible or extremely difficult to trace back to its original source. In the context of PostgreSQL, anonymization techniques are used to ensure the confidentiality and privacy of the data, while still making it available to perform analysis or testing.
 ### Why is anonymization important?
 Anonymization has become a critical aspect of databasing due to the growing need for data protection and compliance with privacy regulations like GDPR, HIPAA, and CCPA. The consequences of non-compliance can result in fines, damage to brand reputation, and potential legal battles.
 ### Techniques for anonymizing data in PostgreSQL
 1. **Data Masking**: Replacing sensitive information with random characters or numbers to make it unrecognizable. For example, replacing a person's name with random letters.
 2. **Generalization**: Aggregating data to a higher level of abstraction, such as converting exact ages to age groups or locations to regions. This will allow you to analyze the data at a higher level without compromising individual privacy.
 3. **Pseudonymization**: Replacing sensitive information with synthetic substitutes, while maintaining a mapping of the original data to the pseudonyms. This allows data to still be useful for analysis purposes but protects identifiable information.
 4. **Data Swapping**: Interchanging some sensitive data between records to create a level of ambiguity on the true data combination. For example, swapping salaries of some employees within a company.
 5. **Random Noise Addition**: Adding random noise to the data elements in a dataset, thus making it more difficult to identify individual records.
 ### Tools for anonymizing data in PostgreSQL
 1. **pg_anonymize**: It's a PostgreSQL extension that can be used to mask and anonymize data. It can generate fake data, mask existing data or shuffle data between rows.
 2. **anon**: A PostgreSQL extension that offers built-in anonymization functions, like data masking, randomizing and anonymization with k-anonymity.
 3. **Data Masker**: A commercial solution that offers tools to mask and pseudonymize sensitive data according to your specific requirements.
 In conclusion, anonymization is an essential skill in any PostgreSQL infrastructure, aiming to protect sensitive and personally identifiable information. Implementing anonymization techniques will enable your organization to comply with data protection regulations and maintain the privacy of individuals, while still enabling you to analyze the patterns and trends in your data.
--- a/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/index.md
@ -1,41 +0,0 @@
 # Configuration Management
 Configuration management is a vital aspect of PostgreSQL database administration as it helps maintain consistency, integrity, and reliability across an entire system. It involves the systematic handling of changes to the database environment, from its initial setup to its ongoing management and maintenance.
 In this section, we'll discuss the key concepts and benefits of configuration management, as well as some useful tools to implement it in a PostgreSQL setting.
 ## Key Concepts of Configuration Management
 - **Configuration Items**: These are the individual components of a system, such as hardware, software, documentation, and people, which need to be managed and tracked throughout their lifecycle.
 - **Version Control**: A systematic approach to managing the changes of configuration items. This enables tracking the modifications made and reverting to previous versions if necessary.
 - **Change Control**: A process to ensure only authorized and appropriate changes are made to a system. This helps maintain consistent system performance and minimizes the risk of unplanned downtime.
 - **Auditing and Reporting**: Regular analysis and documentation of the current state of a system, as well as its change history. This provides valuable insights into the system's performance and potential areas for improvement.
 ## Benefits of Configuration Management
 - **Consistency**: By establishing a baseline of approved configuration items, you can ensure that all components of the system work together as expected.
 - **Efficiency**: Automated processes can reduce human errors and simplify the management of complex environments. This saves time and resources in system administration tasks.
 - **Compliance**: Configuration management helps you adhere to internal policies and external regulations, as well as assess the impact of changes on these requirements.
 - **Security**: By managing and monitoring the changes in your PostgreSQL environment, you can detect potential security risks and respond to them accordingly.
 - **Recovery**: In case of a failure, a well-documented configuration management process allows you to quickly identify the cause and restore the system to a stable state.
 ## Configuration Management Tools for PostgreSQL
 Several tools are available to help you implement configuration management in your PostgreSQL environment, such as:
 - **Ansible**: A widely used open-source configuration management tool, ideal for managing multiple servers and automating tasks like configuration, deployment, and repetitive tasks.
 - **Chef**: A popular tool for managing IT infrastructure, wherein you can write "recipes" to automate tasks, from server deployment to application deployment and management.
 - **Puppet**: Another well-known configuration management solution, which allows you to define the desired state of your infrastructure and automates the process of getting there.
 - **pgbedrock**: A PostgreSQL-specific tool that allows you to manage your database roles, memberships, schema ownership, and privileges in a declarative way, using simple YAML files.
 In conclusion, configuration management plays a crucial role in PostgreSQL automation, ensuring consistent and predictable database performance, and reducing the risks associated with change. By mastering the key concepts and selecting the right tools, you'll be well on your way to efficient and effective PostgreSQL management.
--- a/src/data/roadmaps/postgresql-dba/content/109-application-skills/100-migrations/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/109-application-skills/100-migrations/index.md
@ -1,27 +0,0 @@
 # Migrations
 Migrations are a way to manage and evolve your database schema over time. As your application grows and its requirements change, you'll need to modify the database schema to accommodate new features or enhancements. In PostgreSQL, migrations allow for a structured and version-controlled way to apply these changes incrementally, making it easier to develop, test, and collaborate on database schema updates.
 ## Key Concepts
 - **Migration**: A migration is a single unit of change that affects the schema or data in a database. Each migration encapsulates an operation such as creating, altering, or dropping tables, indices, or constraints.
 - **Migration History**: The sequence of applied migrations is the migration history, and it helps you keep track of the transformations applied to the schema over time. Typically, migrations are tracked using a dedicated table in the database that logs applied migrations and their order.
 - **Up and Down Migrations**: Each migration typically consists of two operations – an "up" operation that applies the change, and a "down" operation that rolls back the change if needed. The up operation moves the schema forward, while the down operation reverts it.
 ## Benefits of Migrations
 - **Version Control**: Migrations help to version control your database schema, making it easier to collaborate with team members and review schema changes in the same way you review application code.
 - **Consistency**: Migrations promote a consistent and reproducible approach to managing schema changes across various environments (e.g., development, testing, production).
 - **Testability**: Migrations allow you to test the effect of schema changes in isolated environments before deploying them to production.
 - **Deployability**: Migrations facilitate automated deployment processes and help reduce the risk of human error during database schema updates.
 ## Migration Tools
 Several tools are available that support migrations in PostgreSQL, including:
 - [@article@Alembic](https://alembic.sqlalchemy.org/en/latest/): A lightweight and extensible migration tool written in Python that works seamlessly with SQLAlchemy (a popular ORM for Python).
 - [@article@Flyway](https://flywaydb.org/): A popular Java-based database migration tool that supports PostgreSQL, among other databases.
 - [@article@Liquibase](https://www.liquibase.org): An open-source, Java-based database migration tool that supports multiple databases including PostgreSQL.
 - [@opensource@Node-pg-migrate](https://github.com/salsita/node-pg-migrate): A convenient migration tool for Node.js applications that use PostgreSQL as their back-end.
 To effectively leverage migrations for your PostgreSQL application, you should choose a migration tool that fits the technology stack and workflow of your team. Once you have selected a tool, start incorporating migrations into your application's development and deployment processes, ensuring consistency, testability, and easier collaboration on schema updates.
--- a/src/data/roadmaps/postgresql-dba/content/109-application-skills/101-queues/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/109-application-skills/101-queues/index.md
@ -1,66 +0,0 @@
 # Queues in PostgreSQL
 Queues are an essential component for building scalable applications, allowing you to manage and process tasks asynchronously. In PostgreSQL, you can implement simple-to-advanced queuing systems using various techniques and extensions. In this section, we'll discuss the basics of implementing queues in PostgreSQL.
 ## Why Use Queues?
 Using queues can improve the performance and user experience of your application by handling intensive tasks more efficiently. They help in:
 - Decoupling components: Your application can be modular and easily maintainable by separating the task processing from the task initiation.
 - Load balancing: Distribute tasks among different workers or processors, enabling better resource utilization.
 - Retry failed tasks: Manage failed tasks more effectively by re-queuing them for retry after a specified duration.
 - Prioritization: Prioritize tasks based on their importance or urgency.
 ## Basic Queues Implementation
 At a high level, a basic queue implementation requires:
 - A table to store the queue. The table should contain the task information, priority, and status (e.g., pending, processing, completed, etc.)
 - Functions to enqueue and dequeue tasks. Enqueue adds a task to the queue while dequeue picks up the next task to process and marks it as "processing."
 - Application code that handles the actual task processing. This part is implemented outside PostgreSQL, in your desired programming language.
 Here is an example of creating a simple queue in PostgreSQL:
 ```sql
 CREATE TABLE task_queue (
  id SERIAL PRIMARY KEY,
  task TEXT NOT NULL,
  priority INTEGER NOT NULL,
  status VARCHAR(32) NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
 );
 ```
 To enqueue a task:
 ```sql
 INSERT INTO task_queue (task, priority) VALUES ('Send email', 1);
 ```
 To dequeue a task:
 ```sql
 WITH next_task AS (
  SELECT id FROM task_queue
  WHERE status = 'pending'
  ORDER BY priority, created_at
  LIMIT 1
  FOR UPDATE SKIP LOCKED
 )
 UPDATE task_queue
 SET status = 'processing'
 WHERE id IN (SELECT id FROM next_task)
 RETURNING *;
 ```
 ## Advanced Queuing Mechanisms
 The simple implementation described above can be further extended to handle more complex requirements, such as:
 - Time-based scheduling: Execute tasks based on specific time intervals or after a delay.
 - Retry attempts and failure handling: Set a limit to the number of retries before marking a task as permanently failed.
 - Dead-letter queues: Store failed tasks separately for further investigation and reprocessing.
 You can also consider using dedicated PostgreSQL extensions like [PGQ](https://wiki.postgresql.org/wiki/PGQ_Tutorial) or third-party queue management systems like [RabbitMQ](https://www.rabbitmq.com/) or [Apache Kafka](https://kafka.apache.org/), which provide more advanced features like message durability, cluster support, and better scalability.
 In conclusion, adding a queue to your PostgreSQL application can help you manage tasks more effectively, provide a better user experience, and make your application more scalable. Start with a basic implementation and then extend it to meet your application's specific requirements.
--- a/src/data/roadmaps/postgresql-dba/content/109-application-skills/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/109-application-skills/index.md
@ -1,29 +0,0 @@
 # Application Skills
 As a database administrator or developer, it's essential to have an understanding of the various application skills required while working with PostgreSQL.
 ## Query optimization
 PostgreSQL offers a highly effective query optimizer, but it's crucial for a developer to understand how to create efficient queries. Knowing how to use `EXPLAIN` and `ANALYZE` to break down a query plan, identify bottlenecks or excessive resource usage, and choose the right indexes are vital skills to optimize query performance.
 ## Connection management & pooling
 When handling multiple client applications using PostgreSQL, it's crucial to manage connections effectively. Connection pooling helps in controlling the number of simultaneous connections to the database, which in turn enhances performance and reduces resource utilization.
 ## Error handling
 Able to handle database errors and exceptions is crucial for any developer. Understanding PostgreSQL error codes, utilizing exception handling in your application's code (e.g., using `TRY...CATCH` statements), and properly logging errors are essential skills for creating robust, fault-tolerant applications.
 ## Backup and recovery
 Ensure the integrity and safety of your data is a responsibility every PostgreSQL developer must uphold. Knowing how to create and manage backups in various formats (`pg_dump`, `pg_basebackup`, etc.), and understanding replication and recovery strategies are vital to prevent data loss and minimize downtime in the event of an issue.
 ## Performance tuning
 Managing a high-performance PostgreSQL database requires developers to monitor and fine-tune various settings such as memory allocation, storage configuration, and cache management. Understanding PostgreSQL's performance metrics and configuration options and having experience with performance monitoring tools are essential for optimizing database performance.
 ## Security & authorization
 Safeguarding the data stored in PostgreSQL is of utmost importance. Implementing best practices for security and authorization, such as encrypting data at rest and in transit, managing authentication methods, and using role-based access control are essential skills for managing a secure PostgreSQL environment.
 By exploring and mastering these application skills, you will not only make yourself more valuable as a PostgreSQL developer but also create better, safer, and more efficient applications and systems.
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/index.md
@ -1,45 +0,0 @@
 # Low-Level Internals
 In this section, we'll delve into some of the low-level internals of PostgreSQL – the inner workings that make this powerful database system function efficiently and effectively.
 ## Overview
 While understanding these low-level details is not mandatory for most users, gaining insights into the internal mechanics can be helpful for more advanced users who want to optimize their database workloads, troubleshoot complex issues, or contribute to PostgreSQL development.
 ## Storage and Disk Layout
 PostgreSQL stores its data on disk in a format that is designed for efficiency and reliability. At a high level, the disk layout consists of the following components:
 - **Tablespaces**: Each tablespace corresponds to a directory on the file system where PostgreSQL stores its data files. PostgreSQL includes a default tablespace called `pg_default`, which is used to store system catalog tables and user data.
 - **Data Files**: Each relation (table, index, or sequence) has one or more data files associated with it. These files contain the actual data as well as metadata about the relation. The names of these files are derived from the object ID (OID) of the relation and are located within the tablespace directory.
 - **WAL (Write-Ahead Log)**: The Write-Ahead Log (WAL) is a crucial component that ensures data consistency and durability. It records all modifications to the database, including inserts, updates, and deletes. PostgreSQL writes WAL records to a separate set of log files before the actual data is updated on disk. In the event of a crash, the WAL can be used to recover the database to a consistent state.
 ## Buffer Cache and Memory Management
 PostgreSQL manages its memory using a combination of shared buffers, local buffers, and the operating system's cache. The main component in this architecture is the shared buffer cache, which is a shared memory area that stores frequently accessed data and metadata.  
 The database system utilizes the following components in managing memory:
 - **Buffer Cache**: PostgreSQL employs a buffer cache to store frequently accessed data and metadata to minimize disk I/O. When a user executes a query, the database first checks if the required data is present in the buffer cache. If not, the data is read from disk and stored in the cache.
 - **Background Writer**: PostgreSQL uses a background writer process to flush dirty buffers (modified data) back to disk periodically. This allows the database to maintain a balance between in-memory data and on-disk storage, ensuring data consistency and durability.
 - **Free Memory Manager**: The free memory manager handles the allocation and deallocation of shared memory for various tasks such as query plans, sort operations, and hash joins.
 ## Query Processing and Execution
 The PostgreSQL query processing and execution pipeline comprises three main stages: Parsing, Rewriting, and Planning/Optimization. This pipeline enables the effective and efficient execution of SQL queries.
 - **Parsing**: The first step involves parsing the query text to construct a syntax tree. The parser identifies SQL keywords, expressions, and other elements, validating their syntax and performing initial semantic checks.
 - **Rewriting**: After parsing, PostgreSQL rewrites the query to apply any relevant rules and views. This stage simplifies and optimizes the query by eliminating unnecessary joins, subqueries, and other constructs.
 - **Planning and Optimization**: The planner generates an optimized, cost-based query execution plan based on available statistics about the database objects, such as table sizes and column distributions.
 - **Execution**: Finally, the executor runs the generated plan, retrieving or modifying data as necessary and returning the results to the user.
 ## Conclusion
 Understanding PostgreSQL's low-level internals, such as its storage architecture, memory management, and query processing, can be beneficial for advanced users seeking to optimize their workloads or troubleshoot complex issues. However, it is important to note that the primary goal remains to effectively use and configure the database system for your specific needs. By gaining insights into these internal mechanics, we hope that you can better appreciate the power and flexibility PostgreSQL offers.
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/101-fine-grained-tuning/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/101-fine-grained-tuning/index.md
@ -1,51 +0,0 @@
 # Fine Grained Tuning
 Fine grained tuning in PostgreSQL refers to the process of optimizing the performance of the database system by adjusting various configuration settings to meet the specific requirements of your application. By tweaking these settings, you can ensure that your PostgreSQL instance runs efficiently and meets the performance needs of your application. This section will provide a brief overview of some important fine-grained tuning methods in PostgreSQL.
 ## Shared Buffers
 Shared buffers are the database's internal cache, where frequently accessed data and other essential system information are stored. Allocating an appropriate amount of shared buffers is crucial for the performance of your PostgreSQL instance.
 - Parameter: `shared_buffers`
 - Default value: 128 megabytes
 - Recommended value: 10-25% of available system memory
 ## Work Memory
 Work memory is the amount of memory that can be used by internal sort and hash operations before switching to a temporary disk file. Increasing work memory can improve the performance of memory-intensive operations.
 - Parameter: `work_mem`
 - Default value: 4 megabytes
 - Recommended value: Set based on the number and complexity of the queries, but be cautious to avoid excessive memory consumption
 ## Maintenance Work Memory
 Maintenance work memory is used for operations such as Vacuum, Index creation, and management of the Free Space Map. Allocating sufficient maintenance work memory can speed up these operations.
 - Parameter: `maintenance_work_mem`
 - Default value: 64 megabytes
 - Recommended value: Consider increasing the value for large databases and databases with a high rate of data churn
 ## Checkpoint Parameters
 Checkpoints are points in time when the database writes all modified data to disk. There are two parameters that control checkpoints:
 - `checkpoint_timeout`: This is the maximum time interval between two checkpoints.
   - Default value: 5 minutes
   - Recommended value: Increase this value if your system has a low rate of data modifications or if your storage subsystem can handle a large number of writes simultaneously.
 - `max_wal_size`: This is the amount of Write-Ahead Log (WAL) data that PostgreSQL will accumulate between checkpoints.
   - Default value: 1 gigabyte
   - Recommended value: Increase this value if checkpoints are causing performance issues or if you have a high rate of data modifications.
 ## Synchronous Commit
 Synchronous commit ensures that a transaction is written to disk before it is considered committed. This provides durability guarantees but can cause a performance overhead.
 - Parameter: `synchronous_commit`
 - Default value: `on`
 - Recommended value: Set to `off` if you can tolerate a slight risk of data loss during a crash, but seek a higher transaction throughput.
 Remember that these values are merely starting points and may need to be adjusted depending on your specific use-case and environment. Monitoring your database performance and making iterative changes is essential for fine-grained tuning of your PostgreSQL instance.
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/102-advanced-sql/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/102-advanced-sql/index.md
@ -1,25 +0,0 @@
 # Advanced SQL
 In this section, we'll explore some of the more advanced features of SQL that can help you take your queries and data manipulation skills to the next level. These topics will provide you with the tools you need to work with complex data structures, optimize query performance, and fine-tune your database activities.
 Here are the main topics we'll cover in this Advanced SQL section:
 - **Subqueries**: Subqueries allow you to use the result of one query as input for another query. We'll discuss how to use subqueries in different parts of your main query, such as the SELECT, FROM, and WHERE clauses.
 - **Common Table Expressions (CTEs)**: CTEs are temporary result sets that can be referenced in a SELECT, INSERT, UPDATE, or DELETE statement. They are particularly useful for breaking down complex queries into simpler, more readable parts.
 - **Window Functions**: Window functions enable you to perform calculations across a set of rows related to the current row. This is useful for tasks like ranking, cumulative sums, and moving averages.
 - **Pivot Tables**: Pivot tables help you reorganize data from long format to wide format (or vice versa). This can make it easier to analyze and summarize data in a meaningful way.
 - **Advanced Joins**: We'll dive deeper into SQL joins by exploring various types of joins such as Self Joins, Lateral Joins, and CROSS JOIN.
 - **Full-Text Search**: Full-text search allows you to query natural language documents stored in your database. We'll look at using PostgreSQL’s built-in text search features, including the tsvector and tsquery data types, as well as text search functions and operators.
 - **Triggers**: Triggers are a way to automatically execute a specified function whenever certain events occur, such as INSERT, UPDATE, DELETE or TRUNCATE operations. We will look at creating triggers and understanding their use cases.
 - **Stored Procedures**: Stored procedures are reusable, precompiled units of code that can be called by applications to perform specific database tasks. We'll discuss creating and invoking stored procedures, and we'll also touch on how they compare to functions in PostgreSQL.
 - **Performance Optimization**: To ensure your PostgreSQL database is running efficiently, it's essential to optimize query performance. We'll highlight some strategies, including indexing, query optimization, and server configuration, to improve efficiency and speed.
 By the end of this section on Advanced SQL, you should have a deeper understanding of these powerful SQL features and techniques that will help you manipulate, analyze, and maintain your data more effectively.
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/index.md
@ -1,67 +0,0 @@
 # Advanced Topics in PostgreSQL
 In this section, we will dive into some advanced topics related to PostgreSQL, aiming to deepen your knowledge and enhance your practical skills when using this powerful database system. The advanced topics we will cover include:
 ## Indexing
 Improve query performance by leveraging indexing. Understand the different types of indexes available in PostgreSQL, such as B-tree, Hash, GiST, SP-GiST, and GIN, and learn how to create and manage them effectively.
 ##1. Index Types
 - **B-tree**: Balances query performance and index size.
 - **Hash**: Best suited for simple equality queries.
 - **GiST**: Supports complex queries and custom data types.
 - **SP-GiST**: Designed for non-balanced tree structures.
 - **GIN**: Optimal for full-text search.
 ##2. Index Management
 - Create and alter indexes
 - Monitor and analyze index usage
 - Optimize indexes for better performance
 ## Performance Tuning
 Learn how to optimize the performance of your PostgreSQL database by tuning various configuration settings and using monitoring tools.
 ##1. Configuration Tuning
 - **Memory**: Adjust shared_buffers, work_mem, maintenance_work_mem, etc.
 - **Write Ahead Logging (WAL)**: Tune parameters like wal_buffers, checkpoint_timeout, checkpoint_completion_target, etc.
 - **Query Planner**: Influence the query optimizer with parameters such as random_page_cost, effective_cache_size, etc.
 ##2. Monitoring Tools
 - Utilize PostgreSQL's `EXPLAIN`, `EXPLAIN ANALYZE`, and `pg_stat_statements` tools to observe query performance.
 ## Partitioning
 Discover how to partition large tables into smaller, more manageable pieces for better performance and easier maintenance.
 ##1. Partitioning Methods
 - Range partitioning
 - List partitioning
 - Hash partitioning
 ##2. Partition Management
 - Create and manage partitions
 - Configure partition constraints and triggers
 ## Full-Text Search
 A crucial feature for many applications, full-text search allows users to search through large text documents efficiently. Learn the basics of PostgreSQL's full-text search capabilities and how to create full-text search queries.
 ##1. Creating Full-Text Search Queries
 - Utilize `tsvector`, `tsquery`, and various text search functions
 - Configure text search dictionaries, parsers, and templates
 ## Concurrency Control
 Understand the importance of ensuring data consistency and concurrency control in multi-user environments, and learn about PostgreSQL's approach to these issues.
 ##1. Transaction Isolation Levels
 - Read committed
 - Repeatable read
 - Serializable
 ##2. Locking Mechanisms
 - Different types of locks in PostgreSQL
 - Techniques for managing and avoiding locks
 By mastering these advanced topics, you will be well-prepared to tackle any challenge that comes your way when working with PostgreSQL. Happy learning!
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/100-system-views/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/100-system-views/index.md
@ -1,51 +0,0 @@
 # System Views in PostgreSQL
 PostgreSQL provides a set of system views that allow you to gain insight into the internal workings of the database. These views can be extremely helpful for troubleshooting and performance tuning as they expose information about various database components such as tables, indexes, schemas, and more. In this section, we'll explore some of the essential system views and their usage to aid in troubleshooting.
 ### pg_stat_activity
 The `pg_stat_activity` view provides a real-time snapshot of the current queries being executed by the PostgreSQL server. It can be used to identify long-running queries, locks, or idle sessions. Example usage:
 ```sql
 SELECT datname, usename, state, query 
 FROM pg_stat_activity;
 ```
 ### pg_stat_user_tables
 This view shows statistics about user tables, such as the number of rows inserted, updated, or deleted, the number of sequential scans and index scans, and more. This information can help you identify performance bottlenecks related to specific tables. Example usage:
 ```sql
 SELECT relname, seq_scan, idx_scan, n_tup_ins, n_tup_upd, n_tup_del 
 FROM pg_stat_user_tables;
 ```
 ### pg_stat_user_indexes
 The `pg_stat_user_indexes` view provides information about the usage of user indexes, such as the number of index scans and the number of rows fetched by them. It helps you identify inefficient or rarely-used indexes. Example usage:
 ```sql
 SELECT relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch 
 FROM pg_stat_user_indexes;
 ```
 ### pg_locks
 The `pg_locks` view displays information about the current locks held within the database. This view is particularly helpful when investigating issues related to deadlocks or contention. Example usage:
 ```sql
 SELECT locktype, relation::regclass, mode, granted, query 
 FROM pg_locks l
 JOIN pg_stat_activity a ON l.pid = a.pid;
 ```
 ### pg_stat_database
 This view provides general database-level statistics such as the number of connections, committed transactions, rollbacks, and more. It is useful for understanding the overall health and workload on your database. Example usage:
 ```sql
 SELECT datname, numbackends, xact_commit, xact_rollback, tup_inserted, tup_updated, tup_deleted 
 FROM pg_stat_database;
 ```
 These are just a few of the many system views available in PostgreSQL. By leveraging these views and their insights into database performance, you can diagnose and solve a variety of issues related to your database system. Be sure to consult the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/monitoring-stats.html) for an exhaustive list of system views and their descriptions.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/101-tools/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/101-tools/index.md
@ -1,38 +0,0 @@
 # Troubleshooting Techniques: Tools
 When working with PostgreSQL, it's essential to have a set of reliable tools at your disposal to effectively diagnose and resolve any issues you may encounter. In this section, we'll briefly introduce you to the essential troubleshooting tools for PostgreSQL.
 ## psql
 `psql` is PostgreSQL's command-line interface (CLI), allowing you to interact with the database server directly. `psql` provides a powerful interface to manage databases, query data, and issue general SQL commands. It is an indispensable tool in your troubleshooting toolkit. Some common tasks you can perform with `psql` include:
 - Connecting to a database
 - Running SQL queries and scripts
 - Inspecting table structures
 - Analyzing query execution plans
 - Managing database users and permissions
 ## pg_stat_statements
 `pg_stat_statements` is an extension that captures detailed information about every SQL statement executed by your PostgreSQL instance. Using this extension, you can identify slow-performing queries, find hotspots in your application, and optimize your database schemas and indexes. Key information provided by `pg_stat_statements` includes:
 - Execution time
 - Rows returned
 - Blocks hit and read
 - Query text
 ## PostgreSQL Logs
 PostgreSQL logs are an invaluable source of information when troubleshooting. They contain detailed information about server activity, such as connection attempts, database queries, and error messages. Be sure to familiarize yourself with the logging configuration options available, as well as the logfile format.
 ## EXPLAIN & EXPLAIN ANALYZE
 The `EXPLAIN` and `EXPLAIN ANALYZE` SQL commands are powerful tools for understanding the inner workings of your queries. `EXPLAIN` provides insight into the query execution plan, showing how the database intends to execute a query. `EXPLAIN ANALYZE` goes one step further, executing the query and providing runtime statistics. Using these commands, you can identify bottlenecks, spot inefficient query plans, and target specific areas for optimization.
 ## pgBadger
 `pgBadger` is a log analyzer for PostgreSQL. It is a Perl script that helps you parse and generate detailed reports from your PostgreSQL log files. `pgBadger` provides various analysis and visualization options, making it easier to spot trends, bottlenecks, and potential issues in your logs.
 ## Conclusion
 These tools are just the starting point for effective PostgreSQL troubleshooting. By leveraging the power of these tools and combining them with a solid understanding of the database system, you'll be well-equipped to diagnose and resolve any issues you encounter.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/102-operating-system-tools/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/102-operating-system-tools/index.md
@ -1,77 +0,0 @@
 # Operating System Tools for Troubleshooting PostgreSQL
 In this section, we will cover some essential operating system tools that are valuable when troubleshooting PostgreSQL issues. Familiarize yourself with these utilities, as they play a crucial role in the day-to-day management of your PostgreSQL database.
 ## ps (Process Status)
 `ps` is a command used to provide information about the currently running processes, including the PostgreSQL server and its child processes. The command has various options to filter and format the output to suit your needs. 
 **Example:**
 ```bash
 ps -u postgres -f
 ```
 This command lists all processes owned by the 'postgres' user in full format.
 ## top and htop
 `top` and `htop` are real-time, interactive process monitoring tools that provide a dynamic view of system processes and the resources they consume. They display information about CPU, memory, and other system statistics essential for troubleshooting performance-related issues in PostgreSQL.
 **Usage:**
 ```bash
 top
 htop
 ```
 ## lsof (List Open Files)
 `lsof` is a utility that displays information about open files and the processes associated with them. This tool can help identify which files PostgreSQL has open and which network connections are active.
 **Example:**
 ```bash
 lsof -u postgres
 ```
 This command lists all open files owned by the 'postgres' user.
 ## netstat (Network Statistics)
 `netstat` is a helpful command that provides information about network connections, routing tables, interface statistics, and more. You can use it to check if PostgreSQL is bound to the correct IP address and listening on appropriate ports.
 **Example:**
 ```bash
 netstat -plunt | grep postgres
 ```
 This command displays listening sockets for the 'postgres' process.
 ## df and du (Disk Usage and Free Space)
 `df` and `du` are file system utilities that allow you to analyze disk usage and free space. Monitoring disk space is crucial for the overall health of your PostgreSQL installation, as running out of disk space can lead to severe performance problems, crashes, or data corruption.
 **Usage:**
 ```bash
 df -h
 du -sh /path/to/postgresql/data
 ```
 ## tail - Tail logs and files
 `tail` is a utility that allows you to display the end of a file or to follow the content of a file in real-time. You can use `tail` to monitor PostgreSQL log files for any errors or information that could be helpful when troubleshooting issues.
 **Example:**
 ```bash
 tail -f /path/to/postgresql/log/logfile
 ```
 This command will show the end of the log file and keep the output updated as new lines are added.
 ## Conclusion
 Understanding and using these operating system tools is a vital first step in diagnosing and troubleshooting any PostgreSQL problems. Make sure you are comfortable with the tools mentioned above and practice using them to manage your databases more effectively. Remember, each tool has additional flags and options that you can explore to tailor the output to your needs. Make sure to consult the relevant man pages or the `--help` option for further information.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/index.md
@ -1,62 +0,0 @@
 # Query Analysis
 Query analysis is an essential troubleshooting technique when working with PostgreSQL. It helps you understand the performance of your queries, identify potential bottlenecks, and optimize them for better efficiency. In this section, we will discuss the key components of query analysis, and demonstrate how to use PostgreSQL tools such as `EXPLAIN` and `EXPLAIN ANALYZE` to gain valuable insights about your queries.
 ## Key Components of Query Analysis
 There are several aspects you need to consider while analyzing a query:
 - **Query Complexity**: Complex queries with multiple joins, aggregations, or nested subqueries can be slow and resource-intensive. Simplifying or breaking down complex queries can improve their performance.
 - **Indexes**: Indexes can make a significant difference when searching for specific rows in big tables. Ensure that your queries take advantage of the available indexes, and consider adding new indexes where needed.
 - **Data Types**: Using inappropriate data types can lead to slow queries and wastage of storage. Make sure you use the correct data types and operators for your specific use case.
 - **Concurrency**: High concurrency can lead to lock contention, causing slow performance. Ensure that your application handles concurrent queries efficiently.
 - **Hardware**: The performance of your queries can be influenced by the hardware and system resources available. Regularly monitoring your system's performance can help you identify hardware-related issues.
 ## Using EXPLAIN and EXPLAIN ANALYZE
 PostgreSQL provides the `EXPLAIN` and `EXPLAIN ANALYZE` commands to help you understand the query execution plan and performance.
 ## EXPLAIN
 `EXPLAIN` displays the query execution plan that the PostgreSQL optimizer generates for a given SQL statement. It does not actually execute the query but shows how the query would be executed.
 Syntax:
 ```sql
 EXPLAIN [OPTIONS] your_query;
 ```
 Example:
 ```sql
 EXPLAIN SELECT * FROM users WHERE age > 30;
 ```
 ## EXPLAIN ANALYZE
 `EXPLAIN ANALYZE` not only displays the query execution plan but also executes the query, providing actual runtime statistics like the total execution time and the number of rows processed. This information can help you identify bottlenecks and analyze query performance more accurately.
 Syntax:
 ```sql
 EXPLAIN ANALYZE [OPTIONS] your_query;
 ```
 Example:
 ```sql
 EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30;
 ```
 ## Understanding the Query Execution Plan
 The output of `EXPLAIN` or `EXPLAIN ANALYZE` provides valuable insights into your query's performance, such as:
 - **Operations**: The sequence of operations such as table scans, index scans, joins, and sorts performed to execute the query.
 - **Cost**: An estimated cost value for each operation, calculated by the PostgreSQL optimizer. Lower cost values indicate better performance.
 - **Total Execution Time**: When using `EXPLAIN ANALYZE`, the actual execution time of the query is displayed, which can help in identifying slow queries.
 - **Row Count**: The estimated or actual number of rows processed by each operation.
 By studying the query execution plan and the associated statistics, you can gain a deeper understanding of your query's performance and identify areas for improvement.
 Now that you have learned about query analysis, you can apply these techniques to optimize your PostgreSQL queries and improve the overall performance of your database system.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/index.md
@ -1,67 +0,0 @@
 # Profiling Tools in PostgreSQL
 Profiling tools in PostgreSQL are essential for diagnosing and resolving performance issues, as well as optimizing and tuning your database system. This section of the guide will cover an overview of commonly used profiling tools in PostgreSQL and how they can be of assistance.
 ## EXPLAIN and EXPLAIN ANALYZE
 `EXPLAIN` and `EXPLAIN ANALYZE` are built-in SQL commands that provide detailed information about the execution plan of a query. They can help in identifying slow or inefficient queries, as well as suggesting possible optimizations.
 - `EXPLAIN` shows the query plan without actually executing the query
 - `EXPLAIN ANALYZE` not only shows the query plan but also executes it, providing actual runtime statistics
 Example usage:
 ```sql
 EXPLAIN SELECT * FROM users WHERE username = 'john';
 EXPLAIN ANALYZE SELECT * FROM users WHERE username = 'john';
 ```
 ## pg_stat_statement
 `pg_stat_statement` is a PostgreSQL extension that provides detailed statistics on query execution. It can help you identify slow queries, as well as analyze and optimize them. To use this extension, you must first enable it in your `postgresql.conf` and restart the server.
 Example configuration:
 ```ini
 shared_preload_libraries = 'pg_stat_statements'
 pg_stat_statements.track = all
 ```
 Once the extension is enabled, you can query the `pg_stat_statements` view to get various statistics on query execution, including total execution time, mean execution time, and the number of times a query has been executed.
 Example query:
 ```sql
 SELECT query, total_time, calls, mean_time
 FROM pg_stat_statements
 ORDER BY total_time DESC
 LIMIT 10;
 ```
 ## auto_explain
 `auto_explain` is another PostgreSQL extension that logs detailed execution plans for slow queries automatically, without requiring manual intervention. To enable this extension, update your `postgresql.conf` and restart the server.
 Example configuration:
 ```ini
 shared_preload_libraries = 'auto_explain'
 auto_explain.log_min_duration = 5000 -- logs query plans taking longer than 5s
 ```
 After enabling `auto_explain`, slow queries will be automatically logged in your PostgreSQL log file along with their execution plans.
 ## pg_stat_activity
 `pg_stat_activity` is a built-in view in PostgreSQL that provides information on currently active queries, including their SQL text, state, and duration of execution. You can use this view to quickly identify long-running or problematic queries in your database.
 Example query:
 ```sql
 SELECT pid, query, state, now() - query_start AS duration
 FROM pg_stat_activity
 WHERE state <> 'idle'
 ORDER BY duration DESC;
 ```
 In summary, profiling tools in PostgreSQL can be indispensable when it comes to identifying, analyzing, and optimizing slow or inefficient queries. By using these tools effectively, you can significantly improve the performance of your database system.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/105-troubleshooting-methods/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/105-troubleshooting-methods/index.md
@ -1,46 +0,0 @@
 # Troubleshooting Techniques in PostgreSQL
 When working with PostgreSQL, you may encounter various challenges or issues that may require troubleshooting. To resolve these challenges efficiently, it is essential to have a good understanding of different troubleshooting methods.
 ## Analyzing Log Files
 PostgreSQL provides detailed log files that can help you diagnose and understand the root cause of issues. Make sure that your PostgreSQL server is configured to log necessary information. To analyze the log files:
 - Locate your PostgreSQL log files. The location may vary based on your operating system and PostgreSQL installation.
 - Open the log files using a text editor or a log analysis tool.
 - Search for error messages, warnings, and other relevant information related to your issue.
 ## Utilizing PostgreSQL Monitoring Tools
 There are various monitoring tools available that can help you monitor the performance, health, and other aspects of your PostgreSQL database:
 - **pg_stat_activity**: This view in PostgreSQL provides information about the current activity of all connections to the database. Use this to identify long-running queries, blocked transactions, or other performance issues.
 - **pg_stat_statements**: This extension tracks and provides data on all SQL queries executed on the database, letting you analyze query performance.
 - **EXPLAIN and EXPLAIN ANALYZE**: These SQL statements help you understand the query execution plan generated by PostgreSQL, which can be useful for optimizing query performance.
 ## Database Configuration Tuning
 Improper database configuration can lead to performance or stability issues. Ensure that your `postgresql.conf` file is tuned correctly.
 - Review the configuration parameters in `postgresql.conf`:
    - Change the shared memory settings (e.g., `shared_buffers`, `work_mem`, and `maintenance_work_mem`) based on available RAM.
    - Adjust the checkpoint-related parameters (`checkpoint_completion_target`, `checkpoint_segments`, and `checkpoint_timeout`) to control the frequency and duration of disk writes.
 - Make changes to the parameters as needed and restart the PostgreSQL server to apply the changes.
 ## Index Management
 Indexes play a crucial role in query performance. Ensure that your database has appropriate indexes in place, and optimize them as needed:
 - Use the `EXPLAIN` command to understand if your queries are using indexes efficiently. 
 - Determine if new indexes are required or existing ones need modifications to support query patterns.
 - Monitor index usage using the `pg_stat_user_indexes` and `pg_stat_all_indexes` system catalog views.
 ## Vacuum and Analyze
 PostgreSQL uses the Multi-Version Concurrency Control (MVCC) mechanism for transaction management, leading to dead rows and bloat. Regular maintenance tasks, like vacuuming and analyzing, are essential to maintain database health:
 - Run the `VACUUM` command to remove dead rows, free up space, and update statistics.
 - Use the `ANALYZE` command to update statistics about the distribution of rows and values in tables, helping the query planner make better decisions.
 - Consider using `autovacuum` to automate vacuuming and analyzing tasks.
 Following these troubleshooting techniques will help you identify, diagnose, and resolve common PostgreSQL issues, ensuring optimal database performance and stability.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/index.md
@ -1,54 +0,0 @@
 # Log Analysis in PostgreSQL
 Log analysis is a critical aspect of troubleshooting PostgreSQL databases. It involves examining the log files generated by the PostgreSQL server to identify errors, performance issues, or abnormal behavior of the database server. This section will guide you through the core concepts of log analysis in PostgreSQL.
 ## Enabling and Configuring Logging in PostgreSQL 
 Make sure that logging is enabled for your PostgreSQL instance. You can enable logging by updating the `postgresql.conf` file, which is stored in your PostgreSQL data directory. Add or modify the following configuration parameters to enable logging:
 ```ini
 logging_collector = on
 log_directory = 'pg_log'
 log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
 log_file_mode = 0600
 ```
 You should restart your PostgreSQL instance after making changes to the configuration file to apply the new settings.
 ## Understanding PostgreSQL Log Levels
 PostgreSQL uses various log levels to categorize log messages. Knowing about these levels can help you filter the logs and identify issues more effectively. The commonly used log levels are:
 - **DEBUG**: Lower-level log messages that provide detailed internal information about the PostgreSQL server, usually not needed during general troubleshooting.
 - **INFO**: High-level informative messages about the PostgreSQL server's activity that aren't related to errors or issues.
 - **NOTICE**: Important messages about events that are not errors but may need administrator attention, like required manual maintenance or an unexpected configuration change.
 - **WARNING**: Messages that indicate possible problems with the database server but don't necessarily affect normal operation.
 - **ERROR**: Messages that report issues affecting the normal operation of the server, such as failed queries, replication issues, or inability to write to the log files.
 To configure the log levels in PostgreSQL, update the `log_min_messages` and `log_min_error_statement` parameters in `postgresql.conf`:
 ```ini
 log_min_messages = warning
 log_min_error_statement = error
 ```
 ## Analyzing Log Files
 Once the logging is enabled and configured, you can start analyzing the log files generated by PostgreSQL. Use any text editor or log analysis tool to open and filter log files. Here are some tips to help you analyze logs effectively:
 - **Filter logs by log level**: Some logs can become quite large. Filtering logs based on their respective log levels can make your analysis process more efficient.
 - **Search logs for specific keywords**: When investigating a specific problem, use the search function in your text editor or log analytics tool to narrow down relevant log messages.
 - **Analyze logs in chronological order**: Logs are generated in chronological order. Analyzing logs following the event's order can help you understand the root cause of an issue.
 - **Cross-reference logs with timestamps**: Compare log messages to the application or system logs to correlate reported issues with other events happening in your environment.
 ## Common Log Analysis Tools
 Several log analysis tools can help in parsing, filtering, and analyzing PostgreSQL logs. Some popular log analysis tools include:
 - **pgBadger**: A fast PostgreSQL log analysis software providing detailed reports, graphs, and statistics. You can find more about it [here](https://github.com/darold/pgbadger).
 - **Logz.io**: A cloud-based log management platform that supports PostgreSQL logs and provides advanced search functionalities. Learn more [here](https://logz.io/).
 - **Graylog**: An open-source centralized log management solution that can handle PostgreSQL logs for real-time analysis. Check out more information [here](https://www.graylog.org/).
 Remember, log analysis is just one part of the troubleshooting process. Gather as much information as possible from other debugging sources like configuration settings, system statistics, and query performance data to identify and resolve issues effectively.
 Explore more about PostgreSQL troubleshooting techniques in the next section by investigating performance optimization strategies.
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/index.md
@ -1,51 +0,0 @@
 # Troubleshooting Techniques for PostgreSQL
 In this section, we'll cover some of the essential troubleshooting techniques for PostgreSQL. When working with a complex database management system like PostgreSQL, it's important to have a good understanding of the tools and methods available to help you diagnose and resolve problems quickly.
 ## Checking logs
 PostgreSQL server logs are the primary source of information for identifying and diagnosing issues. When a problem occurs, you should first examine the logs to gather information about the error.
 You can find log files in the `pg_log` subdirectory of the PostgreSQL data directory, or by checking the `log_directory` configuration parameter in `postgresql.conf`. Some log-related configuration parameters that you might find helpful include:
 - `log_destination`: Specifies where logs should be sent (e.g., stderr, syslog, eventlog, etc.).
 - `logging_collector`: Enables the collection of log files.
 - `log_filename`: Defines the name pattern for log files.
 - `log_truncate_on_rotation`: Determines if older logs should be truncated rather than appended when a new log file is created.
 ## Monitoring system performance and resources
 Monitoring the performance of your PostgreSQL server can help you detect issues related to system resources, such as CPU, memory, and disk usage. Some useful tools for system monitoring include:
 - `pg_stat_activity`: A PostgreSQL view that displays information about the current activities of all server processes.
 - `top`: A Unix/Linux command that provides an overview of the system's processes and their resource usage.
 - `iostat`: A Unix/Linux command that shows disk I/O statistics.
 - `vmstat`: A Unix/Linux command that gives information about system memory, processes, and CPU usage.
 ## Using the EXPLAIN command
 The `EXPLAIN` command in PostgreSQL can help you analyze and optimize SQL queries by providing information about the query execution plan. By using this command, you can identify inefficient queries and make the necessary adjustments to improve performance.
 Usage example:
 ```sql
 EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM my_table WHERE column_1 = 'value';
 ```
 ## PostgreSQL-specific tools
 PostgreSQL provides some specialized tools for troubleshooting and diagnostics:
 - `pg_stat_*` and `pg_statio_*` views: A collection of views that provide detailed information about various aspects of the system, such as table access statistics, index usage, and more.
 - `pg_diag`: A diagnostic tool that collects PostgreSQL information and system data into a single report.
 - `pg_repack`: A utility that helps you to perform maintenance tasks like reorganizing tables or cleaning up dead rows.
 ## Debugging and profiling
 If you're experiencing performance problems or other issues related to the application code, you might need to use debugging and profiling tools. Some examples include:
 - `gdb`: A powerful debugger for Unix/Linux systems that can be used to debug the PostgreSQL server.
 - `pg_debugger`: A PL/pgSQL debugger that allows you to step through PL/pgSQL functions and identify issues.
 - `pg_stat_statements`: A PostgreSQL extension that tracks statistics about individual SQL statements, allowing you to identify slow or problematic queries.
 By understanding and mastering these troubleshooting techniques, you'll be better equipped to diagnose and resolve issues with your PostgreSQL server efficiently and effectively.
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/index.md
@ -1,58 +0,0 @@
 # SQL Optimization Techniques
 Optimizing SQL queries is an essential skill for any database developer or administrator. The goal of query optimization is to reduce the execution time and resource usage to produce the desired output as quickly and efficiently as possible. The following is a brief summary of some common SQL optimization techniques you can use to enhance your PostgreSQL database performance.
 ## Indexes
 Creating appropriate indexes can significantly improve the performance of your queries. Be mindful of both single-column and multi-column index scenarios.
 * Use a single-column index for queries that involve comparisons on the indexed column.
 * Use multi-column indexes for queries that involve multiple columns in the WHERE clause.
 However, adding too many indexes may slow down your database's performance, especially during INSERT and UPDATE operations.
 ## EXPLAIN and ANALYZE
 Before attempting to optimize a query, you should understand its execution plan. PostgreSQL provides the EXPLAIN and ANALYZE commands to help you analyze and optimize query execution plans.
 * EXPLAIN shows the query plan without executing it.
 * EXPLAIN ANALYZE provides detailed runtime statistics alongside the query plan.
 This information can help you spot inefficient parts of your queries and make the necessary adjustments.
 ## LIMIT and OFFSET
 When you only need some specific rows from your query result, use LIMIT and OFFSET instead of fetching all the rows.
 * LIMIT specifies the number of rows to return.
 * OFFSET skips the specified number of rows.
 This can improve performance by reducing the amount of data that needs to be fetched and sent to the client.
 ## Use JOINs efficiently
 Joining tables can be a major source of performance issues. Consider the following when optimizing JOINs:
 * Choose the appropriate type of JOIN: INNER JOIN, LEFT JOIN, RIGHT JOIN, or FULL OUTER JOIN.
 * Be cautious against using too many JOINs in a single query as it may lead to increased complexity and reduced query performance.
 * Use indexes on the columns involved in JOIN operations.
 ## Subqueries and Common Table Expressions (CTEs)
 Subqueries and CTEs are powerful features that can sometimes improve the readability and efficiency of complex queries. However, be cautious of their pitfalls:
 * Avoid correlated subqueries if possible, as they can reduce performance.
 * Use CTEs (WITH clauses) to break down complex queries into simpler parts.
 ## Aggregation and Sorting
 Aggregation and sorting can be computationally expensive operations. Keep these tips in mind:
 * Use GROUP BY efficiently and avoid unnecessary computation.
 * Keep your ORDER BY clauses simple and make use of indexes when possible.
 ## Query Caching
 PostgreSQL supports query caching through the use of materialized views. Materialized views store the results of a query and can be refreshed periodically to improve performance when querying static or infrequently changing datasets.
 In conclusion, optimizing SQL queries is a critical aspect of ensuring the efficient use of database resources. Use these techniques to enhance the performance of your PostgreSQL database, and always be on the lookout for new optimization opportunities.
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/100-acid.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/100-acid.md
--- a/src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/106-adding-extensions.md
+++ b/src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/106-adding-extensions.md
--- a/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/101-advanced-topics/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/101-advanced-topics/index.md
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/102-advanced-sql/104-aggregate-and-window-functions.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/102-advanced-sql/104-aggregate-and-window-functions.md
--- a/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/100-ansible.md
+++ b/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/100-ansible.md
--- a/src/data/roadmaps/postgresql-dba/content/any-programming-language@j5YeixkCKRv0sfq_gFVr9.md
+++ b/src/data/roadmaps/postgresql-dba/content/any-programming-language@j5YeixkCKRv0sfq_gFVr9.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/101-attributes.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/101-attributes.md
--- a/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/102-authentication-models.md
+++ b/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/102-authentication-models.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/101-awk.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/101-awk.md
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/100-b-tree.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/100-b-tree.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/108-backup-validation-procedures.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/108-backup-validation-procedures.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/100-barman.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/100-barman.md
--- a/src/data/roadmaps/postgresql-dba/content/basic-rdbms-concepts@-M9EFgiDSSAzj9ISk-aeh.md
+++ b/src/data/roadmaps/postgresql-dba/content/basic-rdbms-concepts@-M9EFgiDSSAzj9ISk-aeh.md
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/105-brin.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/105-brin.md
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/102-buffer-management.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/102-buffer-management.md
--- a/src/data/roadmaps/postgresql-dba/content/bulk-loading--processing-data@cc4S7ugIphyBZr-f6X0qi.md
+++ b/src/data/roadmaps/postgresql-dba/content/bulk-loading--processing-data@cc4S7ugIphyBZr-f6X0qi.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/102-check-pgactivity.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/102-check-pgactivity.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/104-check-pgbackrest.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/106-monitoring/104-check-pgbackrest.md
--- a/src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/105-checkpoints-background-writer.md
+++ b/src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/105-checkpoints-background-writer.md
--- a/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/102-chef.md
+++ b/src/data/roadmaps/postgresql-dba/content/108-learn-automation/102-configuration-management/102-chef.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/104-columns.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/104-columns.md
--- a/src/data/roadmaps/postgresql-dba/content/configuring@T819BZ-CZgUX_BY7Gna0J.md
+++ b/src/data/roadmaps/postgresql-dba/content/configuring@T819BZ-CZgUX_BY7Gna0J.md
--- a/src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/102-connect-using-psql.md
+++ b/src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/102-connect-using-psql.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/104-constraints.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/104-constraints.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/101-consul.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/101-consul.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/104-core-dumps.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/104-core-dumps.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/101-cte.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/101-cte.md
--- a/src/data/roadmaps/postgresql-dba/content/109-application-skills/103-data-partitioning.md
+++ b/src/data/roadmaps/postgresql-dba/content/109-application-skills/103-data-partitioning.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/105-data-types.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/105-data-types.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/102-data-types.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/102-data-types.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/100-databases.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/100-databases.md
--- a/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/101-default-priviliges.md
+++ b/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/101-default-priviliges.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/101-depesz.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/101-depesz.md
--- a/src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/103-deployment-in-cloud.md
+++ b/src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/103-deployment-in-cloud.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/100-domains.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/100-domains.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/102-ebpf.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/102-ebpf.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/103-etcd.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/103-etcd.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/100-explain.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/100-explain.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/104-explain-dalibo-com.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/103-query-analysis/104-explain-dalibo-com.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/101-filtering-data.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/101-filtering-data.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/100-for-schemas.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/100-for-schemas.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/101-for-tables.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/101-for-tables.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/100-gdb.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/104-profiling-tools/100-gdb.md
--- a/src/data/roadmaps/postgresql-dba/content/get-involved-in-development@NhodBD8myUTljNdn3y40I.md
+++ b/src/data/roadmaps/postgresql-dba/content/get-involved-in-development@NhodBD8myUTljNdn3y40I.md
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/104-gin.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/104-gin.md
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/102-gist.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/102-gist.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/105-troubleshooting-methods/102-golden-signals.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/105-troubleshooting-methods/102-golden-signals.md
--- a/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/100-grant-revoke.md
+++ b/src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/100-grant-revoke.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/102-grep.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/106-log-analysis/102-grep.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/104-grouping.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/104-grouping.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/100-ha-proxy.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/100-ha-proxy.md
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/101-hash.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/101-hash.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/101-helm.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/101-helm.md
--- a/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/index.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/102-import-export-using-copy.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/102-import-export-using-copy.md
--- a/src/data/roadmaps/postgresql-dba/content/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/index.md
@ -1 +0,0 @@
 # 
--- a/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/index.md
+++ b/src/data/roadmaps/postgresql-dba/content/112-sql-optimization-techniques/100-indexes-usecases/index.md
--- a/src/data/roadmaps/postgresql-dba/content/infrastructure-skills@zlqSX0tl7HD9C1yEGkvoM.md
+++ b/src/data/roadmaps/postgresql-dba/content/infrastructure-skills@zlqSX0tl7HD9C1yEGkvoM.md
--- a/src/data/roadmaps/postgresql-dba/content/installation-and-setup@FtPiBWMFhjakyXsmSL_CI.md
+++ b/src/data/roadmaps/postgresql-dba/content/installation-and-setup@FtPiBWMFhjakyXsmSL_CI.md
--- a/src/data/roadmaps/postgresql-dba/content/introduction@lDIy56RyC1XM7IfORsSLD.md
+++ b/src/data/roadmaps/postgresql-dba/content/introduction@lDIy56RyC1XM7IfORsSLD.md
--- a/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/102-operating-system-tools/102-iotop.md
+++ b/src/data/roadmaps/postgresql-dba/content/111-troubleshooting-techniques/102-operating-system-tools/102-iotop.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/103-joining-tables.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/103-joining-tables.md
--- a/src/data/roadmaps/postgresql-dba/content/joining-tables@umNNMpJh4Al1dEpT6YkrA.md
+++ b/src/data/roadmaps/postgresql-dba/content/joining-tables@umNNMpJh4Al1dEpT6YkrA.md
@ -0,0 +1,55 @@
 # Import and Export using COPY
 In PostgreSQL, one of the fastest and most efficient ways to import and export data is by using the `COPY` command. The `COPY` command allows you to import data from a file, or to export data to a file from a table or a query result.
 ## Importing Data using COPY
 To import data from a file into a table, you can use the following syntax:
 ```sql
 COPY <table_name> (column1, column2, ...)
 FROM '<file_path>' [OPTIONS];
 ```
 For example, to import data from a CSV file named `data.csv` into a table called `employees` with columns `id`, `name`, and `salary`, you would use the following command:
 ```sql
 COPY employees (id, name, salary)
 FROM '/path/to/data.csv'
 WITH (FORMAT csv, HEADER true);
 ```
 Here, we're specifying that the file is in CSV format and that the first row contains column headers.
 ## Exporting Data using COPY
 To export data from a table or a query result to a file, you can use the following syntax:
 ```sql
 COPY (SELECT ... FROM <table_name> WHERE ...)
 TO '<file_path>' [OPTIONS];
 ```
 For example, to export data from the `employees` table to a CSV file named `export.csv`, you would use the following command:
 ```sql
 COPY (SELECT * FROM employees)
 TO '/path/to/export.csv'
 WITH (FORMAT csv, HEADER true);
 ```
 Again, we're specifying that the file should be in CSV format and that the first row contains column headers.
 ## COPY Options
 The `COPY` command offers several options, including:
 - `FORMAT`: data file format, e.g., `csv`, `text`, or `binary`
 - `HEADER`: whether the first row in the file is a header row, `true` or `false`
 - `DELIMITER`: field delimiter for the text and CSV formats, e.g., `','`
 - `QUOTE`: quote character, e.g., `'"'`
 - `NULL`: string representing a null value, e.g., `'\\N'`
 For a complete list of `COPY` options and their descriptions, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/sql-copy.html).
 Remember that to use the `COPY` command, you need to have the required privileges on the table and the file system. If you can't use the `COPY` command due to lack of privileges, consider using the `\copy` command in the `psql` client instead, which works similarly, but runs as the current user rather than the PostgreSQL server.
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/102-keep-alived.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/107-load-balancing/102-keep-alived.md
--- a/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/103-lateral-join.md
+++ b/src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/103-lateral-join.md
--- a/src/data/roadmaps/postgresql-dba/content/learn-sql@ANUgfkADLI_du7iRvnUdi.md
+++ b/src/data/roadmaps/postgresql-dba/content/learn-sql@ANUgfkADLI_du7iRvnUdi.md
--- a/src/data/roadmaps/postgresql-dba/content/learn-to-automate@e5s7-JRqNy-OhfnjTScZI.md
+++ b/src/data/roadmaps/postgresql-dba/content/learn-to-automate@e5s7-JRqNy-OhfnjTScZI.md
--- a/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/103-lock-management.md
+++ b/src/data/roadmaps/postgresql-dba/content/110-advanced-topics/100-low-level-internals/103-lock-management.md
--- a/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/100-logical-replication.md
+++ b/src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/100-logical-replication.md
--- a/src/data/roadmaps/postgresql-dba/content/113-get-involved-in-development/100-mailing-lists.md
+++ b/src/data/roadmaps/postgresql-dba/content/113-get-involved-in-development/100-mailing-lists.md
--- a/Show More
+++ b/Show More