Common operation and maintenance sql postgres

1, check the database size

select pg_database_size('log_analysis');

postgres=# select pg_database_size('postExpress');
 pg_database_size 
------------------
    4417902485676
(1 row)

SELECT pg_size_pretty(pg_database_size('postExpress'));

postExpress=# SELECT pg_size_pretty(pg_database_size('postExpress'));
 pg_size_pretty 
----------------
 4115 GB
(1 row)

2, in order to query the database size

select pg_database.datname, pg_size_pretty (pg_database_size(pg_database.datname)) AS size from pg_database;

3, in order to see the index

select indexrelname, pg_size_pretty(pg_relation_size(relid)) from pg_stat_user_indexes where schemaname='public' order by pg_relation_size(relid) desc;

4, view the size of all tables

select relname, pg_size_pretty(pg_relation_size(relid)) from pg_stat_user_tables where schemaname='public' order by pg_relation_size(relid) desc;

5, check the temporary files

SELECT datname, temp_files AS "Temporary files",temp_bytes AS "Size of temporary files" FROM pg_stat_database ;

Temporary files are stored by connecting the rear end of the session or file, or they can be used as buffer resource pool. These files are stored separately from the shared resource space.

Important: The view pg_stat_database temp_files temp_bytes column and collect statistical information (cumulative value) polymerization. This is by design, because these reset the counter reset can only be restored when the server is started by, for example, when the server has just shut down the server crashes and point in time recovery (PITR). Therefore, the best approach is to monitor the number and size of these files grows, and not only see the output.

6, copy the query and confirm the presence and size of grooves:

PostgreSQL v9

select slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) as 
replicationSlotLag, active from pg_replication_slots ;

PostgreSQL v10 and v11

select slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) as replicationSlotLag, 
active from pg_replication_slots ;

7, after determining the copy currently unused slot (active state is False), delete the duplicate query groove

select pg_drop_replication_slot('Your_slotname_name');

8, this pg_replication_slotsview provides a list of all replication slots and their current status of the currently existing database cluster

select * from pg_replication_slots;

Cross-read-only copy area

If you use a read-only copy of the inter-regional, create a physical copy slot on the primary instance. If the inter-regional read-only copy fails, the storage space on the primary database instance may be affected, because the WAL files are not copied to the read-only copy. You can use CloudWatch targets "the oldest copy trough latency" and "transaction log disk use" to determine the most lagged copies on WAL data received, and how much there is storage space for WAL data.

9, the number of inquiries connected

select count(1) from pg_stat_activity;

10, the query maximum number of connections

show max_connections;

11, export the data to a csv file

copy (select * from test) to '/data/test.csv' with csv header;

12, the query sql statements consuming the most CPU's

To get the process of PID, order processes are consuming the most cpu

ps aux|head -1;ps aux|grep -v PID|sort -rn -k +3|head

select procpid, start, now() - start as lap, current_query 
from 
(select backendid, pg_stat_get_backend_pid(s.backendid) as procpid, pg_stat_get_backend_activity_start(s.backendid) as start, pg_stat_get_backend_activity(s.backendid) as current_query 
from 
(select pg_stat_get_backend_idset() as backendid) as s 
) as s 
where 
current_query <> '<IDLE>' and procpid IN （17637,123,321） --加入查找到的进程ID
order by 
lap desc;

13, stop sql is being executed

kill select query, to update, delete and DML does not take effect) 
the SELECT pg_cancel_backend (PID); 

the kill off various operations (select, update, delete, drop, etc.) 
the SELECT pg_terminate_backend (PID);

14, use the "explain your_statements" way to view the execution plan of SQL statements

explain delete from p_table ;

Here, it should be noted that, explain analyze analyzes the SQL statement execution plan and really execute SQL statements. And, by default, the transaction PostgreSQL databases is automatically turned on submission. So, for the DML statements, if you want to use explain analyze to see its execution plan, then we have to pay particular attention to the

explain analyze delete from p_table ;

explain analyze delete from p_table; see a delete operation SQL execution plan, the result is true to delete data in tables and presented.
For all DML operations, if you just want to see their implementation plans explain analyze, then, need prior to execution, display on the transaction, and then view the execution plan, the last roll back the transaction.　

postgres=# begin;
BEGIN
postgres=# explain analyze xxxxxxxxx;
postgres=# rollback;
ROLLBACK
postgres=#

15, a query using the index record

select * from pg_stat_all_indexes where schemaname = 'postgres' and relname = 'table / index / view name';

Reference Material: https://aws.amazon.com/cn/premiumsupport/knowledge-center/diskfull-error-rds-postgresql/

https://www.postgresql.org/docs/current/index.html

http://www.oracleonlinux.cn/2018/08/differences-between-explain-and-explain-analyze/

Common operation and maintenance sql postgres

Guess you like