SELECT e INSERT em dados armazenados em um servidor PostgreSQL remoto.
Atualmente, apenas as versões 12 ou superiores do PostgreSQL são compatíveis com o motor de tabela.
Criando uma tabela
- Os nomes das colunas devem ser os mesmos da tabela PostgreSQL original, mas você pode usar apenas algumas delas e em qualquer ordem.
- Os tipos das colunas podem ser diferentes dos da tabela PostgreSQL original. O ClickHouse tenta converter os valores para os tipos de dados do ClickHouse.
- A configuração external_table_functions_use_nulls define como tratar colunas Nullable. Valor padrão: 1. Se for 0, a função de tabela não cria colunas Nullable e insere valores padrão em vez de valores nulos. Isso também se aplica a valores NULL dentro de arrays.
host:port— Endereço do servidor PostgreSQL.database— Nome do banco de dados remoto.table— Nome da tabela remota ou uma consulta passada ao PostgreSQL como está (veja Passando uma consulta em vez de um nome de tabela).user— Usuário do PostgreSQL.password— Senha do usuário.schema— Esquema de tabela não padrão. Opcional.on_conflict— Estratégia de resolução de conflitos. Exemplo:ON CONFLICT DO NOTHING. Opcional. Observação: adicionar esta opção tornará a inserção menos eficiente.
TLS/SSL
Os parâmetros TLS/SSL são encaminhados aolibpq e podem ser definidos como chaves de uma coleção nomeada ou como argumentos chave-valor finais: sslmode (disable, allow, prefer, require, verify-ca ou verify-full), além dos certificados e da chave, em uma de duas formas. Quando não são definidos, aplicam-se os padrões do libpq (sslmode=prefer).
sslrootcert(certificado da CA ou o valor especialsystem),sslcert(certificado do cliente) esslkey(chave privada do cliente) são caminhos para arquivos locais do servidor. Eles só podem ser especificados em uma coleção nomeada definida no arquivo de configuração do servidor e não podem ser substituídos em uma consulta: o servidor abre os arquivos com seus próprios privilégios.sslrootcert_pem,sslcert_pemesslkey_pemaceitam o conteúdo literal do arquivo correspondente em vez de um caminho. Podem ser especificados em qualquer lugar — em uma consulta, em uma coleção nomeada criada com SQL ou como substituição de uma coleção nomeada — e são mascarados nos logs e em consultasSHOW, como uma senha.
Configurações
O pool de conexões usado pelo motor de tabelaPostgreSQL (e pela função de tabela postgresql) pode ser configurado para cada tabela com uma cláusula SETTINGS. Quando uma configuração não é especificada, o valor padrão é o da configuração postgresql_* correspondente no nível da consulta.
postgresql_connection_pool_size
Tamanho do pool de conexões (se todas as conexões estiverem em uso, a consulta aguardará até que alguma delas seja liberada). Deve ser maior que zero.
Valor padrão: 16.
postgresql_connection_pool_wait_timeout
Tempo limite, em milissegundos, para push/pop no pool de conexões quando o pool está vazio. 0 significa que a operação bloqueia quando o pool está vazio.
Valor padrão: 5000.
postgresql_connection_pool_retries
Número de tentativas de nova tentativa ao obter/devolver conexões do pool.
Valor padrão: 2.
postgresql_connection_pool_auto_close_connection
Feche a conexão antes de devolvê-la ao pool.
Valor padrão: false.
postgresql_connection_attempt_timeout
Tempo limite de conexão, em segundos, para uma única tentativa de conexão ao endpoint do PostgreSQL. O valor é passado como parâmetro connect_timeout na URL de conexão.
Valor padrão: 2.
Exemplo:
Detalhes de implementação
As consultasSELECT no PostgreSQL são executadas como COPY (SELECT ...) TO STDOUT dentro de uma transação PostgreSQL somente leitura, com commit após cada consulta SELECT.
Cláusulas WHERE simples, como =, !=, >, >=, <, <= e IN, são executadas no servidor PostgreSQL.
Todas as junções, agregações, ordenações, condições IN [ array ] e a restrição de amostragem LIMIT são executadas no ClickHouse somente após a conclusão da consulta ao PostgreSQL.
Passando uma consulta em vez de um nome de tabela
Em vez de um nome de tabela, o argumentotable pode ser uma consulta SELECT passada ao PostgreSQL como está. A estrutura da tabela é inferida a partir do resultado da consulta. A consulta pode ser escrita como uma subconsulta ou encapsulada na função query:
INSERT nela não é permitido. A mesma sintaxe também é compatível com a função de tabela postgresql.
A forma de subconsulta
(SELECT ...) é analisada pelo ClickHouse e reserializada no dialeto PostgreSQL (aspas de identificadores do PostgreSQL e escapamento de literais de string) antes de ser enviada ao servidor. Portanto, ela deve ser um ClickHouse SQL válido. Para passar sintaxe específica do PostgreSQL que o ClickHouse não analisa, use a forma query('...'), cujo texto é enviado ao PostgreSQL literalmente.Qualquer WHERE, LIMIT, agregação etc. externo da consulta ClickHouse circundante não é delegado à consulta passada — ele é aplicado no ClickHouse após a obtenção do resultado completo da consulta. Para restringir os dados lidos do PostgreSQL, coloque o filtro dentro da consulta passada. Com external_table_strict_query = 1, um filtro externo nas colunas da tabela é rejeitado com uma exceção em vez de ser aplicado localmente, pois não pode ser delegado à consulta passada. A verificação abrange o predicado WHERE de nível superior e cada conjunção de um AND de nível superior. Um PREWHERE nas colunas desta tabela não é um caso para essa configuração: este motor de tabela não oferece suporte a PREWHERE, e tal consulta é rejeitada com ILLEGAL_PREWHERE independentemente da configuração. A verificação é executada somente onde um filtro poderia ser delegado: quando esta tabela é a única tabela da consulta, em qualquer lado de um INNER JOIN ou no lado preservado de uma junção externa (o lado esquerdo de um LEFT JOIN, o lado direito de um RIGHT JOIN). No lado não preservado de um LEFT/RIGHT JOIN e em qualquer lado de um FULL JOIN, nada é delegado e nada é verificado; portanto, um filtro nas colunas desta tabela é aplicado localmente após a junção mesmo no modo estrito. Onde a verificação é executada, um predicado que referencia outras tabelas unidas na consulta circundante não é delegado e é excluído da verificação, quer ele referencie apenas o lado unido ou o misture com esta tabela dentro de uma expressão que não seja AND (por exemplo, um OR); tal predicado mantém seu ponto usual de avaliação no ClickHouse (WHERE após a junção, PREWHERE antes dela) e não é rejeitado.INSERT no PostgreSQL são executadas como COPY "table_name" (field1, field2, ... fieldN) FROM STDIN dentro de uma transação PostgreSQL, com commit automático após cada instrução INSERT.
Os tipos Array do PostgreSQL são convertidos em arrays do ClickHouse.
Atenção: no PostgreSQL, um dado de array, criado como
type_name[], pode conter arrays multidimensionais com números diferentes de dimensões em diferentes linhas da mesma coluna da tabela. Já no ClickHouse, só é permitido ter arrays multidimensionais com a mesma quantidade de dimensões em todas as linhas da mesma coluna da tabela.|. Por exemplo:
0.
No exemplo abaixo, a réplica example01-1 tem a maior prioridade: