Início / user-185083

Emre Sevinç's questions

Martin Hope
Emre Sevinç
Asked: 2021-06-26 05:45:38 +0800 CST
  • 3

Estou recebendo o seguinte erro ao tentar restaurar meu arquivo de despejo para outro servidor PostgreSQL (local) (executando no Debian GNU/Linux 10.10):

pg_restore: error: could not execute query: ERROR:  option "locale" not recognized

porque de fato tem a seguinte linha:

CREATE DATABASE "REMOTE_DB" WITH TEMPLATE = template0 ENCODING = 'UTF8' LOCALE = 'en_GB.UTF-8';

E sim, eu sei que o comando PostgreSQL 12 CREATE DATABASE não tem uma LOCALEopção.

O que não entendo:

  • a versão do próprio PostgreSQL que estou usando no meu servidor local é relatada como 12.7
  • a versão do pg_dumpque estou usando no meu servidor local é relatada como 12.7
  • a versão do pg_restoreque estou usando no meu servidor local é relatada como 12.7
  • o banco de dados remoto PostgreSQL cujo dump eu criei usando pg_dumpé a versão 12.7, não 13 .

Deixe-me verificar estes um por um:

Meu servidor local:

$ sudo -u postgres psql -c 'select version();'
                                                     version
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.7 (Debian 12.7-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

Minha pg_dumpversão local:

$ pg_dump --version
pg_dump (PostgreSQL) 12.7 (Debian 12.7-1.pgdg100+1)

Minha pg_restoreversão local:

$ pg_restore --version
pg_restore (PostgreSQL) 12.7 (Debian 12.7-1.pgdg100+1)

Vamos verificar a versão PostgreSQL do banco de dados REMOTE :

$ psql --host=REMOTE_HOST_IP_ADDRESS --dbname=REMOTE_DB --username=DB_USER -c 'select version();'
Password for user DB_USER:
                                                             version
----------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.7 (Debian 12.7-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit
(1 row)

Foi assim que criei o arquivo de despejo:

$ pg_dump --verbose \
  --create \
  --clean \
  --if-exists \
  --format=custom \
  --compress=5 \
  --host=REMOTE_HOST_IP_ADDRESS --dbname=REMOTE_DB --username=DB_USER \
  --schema=public --table=TABLE_NAME\
  > db.dump

E foi assim que tentei restaurá-lo no servidor local que está executando o PostgreSQL 12:

$ sudo -u postgres \
pg_restore --verbose \
  --create \
  --clean \
  --jobs=8 \
  --format=custom \
  --dbname=postgres \
  db.dump

O PostgreSQL 13 está instalado, mas não está sendo executado neste servidor local:

$ systemctl status [email protected]
● [email protected] - PostgreSQL Cluster 13-main
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled-runtime; vendor preset: enabled)
   Active: failed (Result: protocol) since Thu 2021-06-24 07:59:24 UTC; 1 day 5h ago
  Process: 562 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect 13-main start (code=exited, status=1/FAILURE)

O PostgreSQL 12 está em execução:

$ systemctl status [email protected]
● [email protected] - PostgreSQL Cluster 12-main
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled-runtime; vendor preset: enabled)
   Active: active (running) since Thu 2021-06-24 07:59:26 UTC; 1 day 5h ago
  Process: 556 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect 12-main start (code=exited, status=0/SUCCESS)
 Main PID: 595 (postgres)
    Tasks: 9 (limit: 36863)
   Memory: 235.7M
   CGroup: /system.slice/system-postgresql.slice/[email protected]
           ├─595 /usr/lib/postgresql/12/bin/postgres -D /var/lib/postgresql/12/main -c config_file=/etc/postgresql/12/main/postgresql.conf
           ├─678 postgres: 12/main: checkpointer
           ├─679 postgres: 12/main: background writer
           ├─680 postgres: 12/main: walwriter
           ├─681 postgres: 12/main: autovacuum launcher
           ├─682 postgres: 12/main: stats collector
           ├─683 postgres: 12/main: TimescaleDB Background Worker Launcher
           ├─684 postgres: 12/main: logical replication launcher
           └─685 postgres: 12/main: TimescaleDB Background Worker Scheduler

Resumindo, minha pergunta é:

  • por que recebo essa LOCALEopção não suportada no arquivo de despejo gerado pelo pg_dump, enquanto a versão REMOTE do PostgreSQL, bem como a pg_dumpversão local, é relatada como 12.7 e não 13 ?

O que mais devo verificar?

postgresql pg-dump
Martin Hope
Emre Sevinç
Asked: 2021-06-18 01:10:00 +0800 CST
  • 0

Em um banco de dados PostgreSQL 12.7 'baunilha' , geralmente executo a seguinte consulta para saber o número estimado de linhas em tabelas com mais de 100 milhões de linhas:

----------------------------------------------------------
-- Return the estimated number of rows for the given table
----------------------------------------------------------
SELECT reltuples::bigint AS estimate_number_of_rows
FROM   pg_class
WHERE  oid = to_regclass('name_of_some_big_table');

Esse tipo de consulta não funciona para uma hipertabela distribuída em nossa instalação do TimescaleDB de vários nós .

Verifiquei a referência da API do TimescaleDB , mas não consegui encontrar o que estou procurando.

Existe uma consulta tão direta para retornar rapidamente o número estimado de linhas em uma hipertabela distribuída?

timescaledb
Martin Hope
Emre Sevinç
Asked: 2021-06-11 23:46:58 +0800 CST
  • 2

Eu tenho uma grande tabela (vamos chamá-la big_tablede ) em um banco de dados PostgreSQL 12.7 rodando em um servidor Debian GNU/Linux. A máquina possui 8 GB de RAM e 4 núcleos de CPU , sendo a maior parte dedicada a este servidor PostgreSQL.

Atualmente, isso big_tabletem cerca de 103 milhões de linhas que contêm dados de séries temporais (por exemplo, os dados não são atualizados, apenas inseridos ou excluídos). Quase todo mês, excluo cerca de 25 a 30 milhões de linhas dessa tabela. Essas linhas excluídas correspondem a um intervalo de tempo consecutivo (por exemplo, algo como "DELETE ... entre 1 de março e 30 de março"). Essas DELETEoperações levam de 10 a 30 minutos para serem concluídas. Este tipo de padrão de uso está em vigor há mais de 6 meses .

O tamanho da tabela é de aproximadamente 46 GB e os índices dessa tabela somam cerca de 61 GB .

Há um aplicativo que insere 10s de linhas a cada poucos segundos para this big_table, e outro aplicativo da Web voltado para o usuário que lê essa tabela para plotar alguns valores recentes.

Toda vez que executo a DELETEoperação que exclui de 25 a 30 milhões de linhas (no final do mês), vejo que o AUTOVACUUM entra em ação e começa a funcionar.

Eu queria verificar algumas estatísticas sobre como esses AUTOVACUUM e executei a seguinte consulta SQL nesse banco de dados:

SELECT relname, last_vacuum, vacuum_count, autovacuum_count, last_autovacuum, autoanalyze_count, last_autoanalyze
FROM pg_stat_user_tables 
WHERE relname = 'big_table' ;

Para minha surpresa, deu o seguinte resultado:

|relname     |last_vacuum|vacuum_count|autovacuum_count|last_autovacuum|autoanalyze_count|last_autoanalyze|
|------------|-----------|------------|----------------|---------------|-----------------|----------------|
|big_Table   |           |0           |0               |               |0                |                |

Estou tentando entender o seguinte:

  • Por que são autovacuum_counte auto_analyzecount zero ?
  • Por que são last_autovacuume last_autoanalyze NULL ?

Infelizmente, a documentação oficial em https://www.postgresql.org/docs/12/monitoring-stats.html não foi muito útil para mim.

  • Pode ser o caso de AUTOVACUUM iniciar mas não terminar? E semelhante para ANALISAR?
  • Se sim, qual pode ser a causa raiz?
  • O que devo verificar para verificar se a aspiração de rotina faz o que deveria fazer?
postgresql autovacuum