Vao Tsun's questions

Se eu acertar, as configurações são hierárquicas:

postgres.conf->
postgres.auto.conf (ALTER SYSTEM)->
ALTER DATABASE(where applicable)->
ALTER USER(where applicable)->
SET SESSION(where applicable)->
SET LOCAL(where applicable)

digamos que eu tenha enable_seqscandefinido para offem algum momento. SHOWou current_setting(ou pg_settingsme mostrará apenas o valor atual. Mas para verificar por que estou com isso, tenho que verificar toda a cadeia. Por exemplo, eu suspeito que alguém o configurou por usuário ou por banco de dados, ou em auto.conf- para descobrir quão ampla é a configuração, tenho que verificar todos. Caso contrário, a redefinição do valor pode falhar, por exemplo:

vao=# show enable_seqscan;
 enable_seqscan
----------------
 off
(1 row)

vao=# set enable_seqscan to default;
SET
vao=# show enable_seqscan;
 enable_seqscan
----------------
 off
(1 row)

Porque é assim para o usuário vao, ou para o banco de dados vao, ou mais profundo...

Qual é uma maneira curta de encontrar a fonte primária do valor atual?.. Ou, de preferência, a matriz de todas as fontes para a configuração. Existe alguma interface ou hack de macaco?

atualização para refletir a brilhante resposta de Abelisto:

source, sourcefile from pg_settingsé uma fonte maravilhosa de informação, ainda estou pedindo uma maneira de verificar por esses motivos: para ver o ou databaseeu tenho que fazer login novamente - obviamente. Portanto, antes que eles sejam realmente aplicados à sessão, não posso verificá-los. local e session set mostra tanto SESSION (que tipo de razoável também) e por último ainda tenho que redefinir para o padrão passo a passo toda a hierarquia. Por exemplo:usersource

vao=# select setting, source, sourcefile from pg_settings where name = 'enable_seqscan';
 setting |  source  | sourcefile
---------+----------+------------
 off     | database |
(1 row)

vao=# select * from pg_file_settings where name = 'enable_seqscan';
                    sourcefile                     | sourceline | seqno |      name      | setting | applied | error
---------------------------------------------------+------------+-------+----------------+---------+---------+-------
 /etc/postgresql/9.6/main/a                        |          1 |     1 | enable_seqscan | off     | f       |
 /var/lib/postgresql/9.6/main/postgresql.auto.conf |          3 |    26 | enable_seqscan | on      | t       |
(2 rows)

Portanto, se eu não verificar todas as fontes, minhas alterações não poderão ser respeitadas.

https://www.postgresql.org/docs/current/static/standby-settings.html

O atraso ocorre apenas em registros WAL para confirmações de transação. Outros registros são reproduzidos o mais rápido possível, o que não é um problema porque as regras de visibilidade do MVCC garantem que seus efeitos não sejam visíveis até que o registro de confirmação correspondente seja aplicado.

Eu pensei que enquanto o xlog de replicação de streaming é reproduzido no escravo. As transações locais não são reproduzidas. As instruções remotas que ignoram WAL (por exemplo create table nologging) não são reproduzidas no escravo. Agora estou confuso - quais são esses outros registros que são reproduzidos sem esperarrecovery_min_apply_delay ? ..

• servidor estrangeiro 9.2

• servidor local 9.5

• mesa é 10GB

• transferência de dados realizada na mesma interface de rede que o servidor externo funciona

• nenhum índice definido nos dados

• à moda antiga:

  1. copiar para - 2:36
  2. scp - 08:17
  3. copiar de - 10:11

• postgres_fdw:

  1. quando o old way terminou, ele fez 800 MB deinsert into .. select * from foreign_table

Perdi algo na configuração (o que significa que posso melhorá-lo) ou postgres_fdwsimplesmente não é para carregamento em massa (o que significa que não posso melhorá-lo)?

(Eu o uso para reconciliação de pequenas quantidades de dados e funciona bem. A ideia de insert select from fdw, em vez de executar comandos bash, parecia tão legal.)*

Eu tentei o psql para o servidor remoto do servidor local e \copy table- seis minutos - mais rápido que o ssh.

A fetch_sizeopção, não disponível antes de 9.6, pode ser simulada dblink_fetch(CURSOR, fetch_size)- veja minha resposta abaixo.

Na página de documentação do Postgres Tipos de data/hora , ele diz:

Para os tipos de tempo, o intervalo permitido de p é de 0 a 6 quando o armazenamento inteiro de oito bytes é usado, ou de 0 a 10 quando o armazenamento de ponto flutuante é usado.

Tentei produzir instrução SQL com time(p), quando p=10? eu sempre consigo

ATENÇÃO: Precisão de TEMPO(10) reduzida ao máximo permitido, 6

Não importa se eu coloco segundos em float ou não. Percebo que estou perdendo algo muito óbvio. Por favor, dê um exemplo quando p = 10.

De acordo com os documentos , jsonb_each_text(jsonb)retorna

conjunto de texto-chave, texto de valor

mas se você pg_typeof(value)no resultado mostra jsonb, por exemplo:

SELECT *, pg_typeof(key) AS type_key, pg_typeof(value) AS type_value
FROM jsonb_each('{"2": "-200.08"}');

 key |   value   | type_key | type_value 
-----+-----------+----------+------------
 2   | "-200.08" | text     | jsonb

ATUALIZAÇÃO: Eu confundi documentos com em jsonb_each_textvez dejsonb_each