All perguntas(dba)

tentando instalar o cassandra via pacote rpm e encontrei problema com o baseurl. Alguém sabe, problema com redirecionamento?

[vic@ol9-135 ~]$ sudo yum --disablerepo="*" --enablerepo="cassandra" list available
Apache Cassandra                                                                                                                7.5 kB/s |  11 kB     00:01
Error: Failed to download metadata for repo 'cassandra': repomd.xml parser error: Parse error at line: 1 (EntityRef: expecting ';'
)

ou com jfog (infelizmente não estou familiarizado com jfrog).?

[vic@ol9-135 ~]$ wget https://redhat.cassandra.apache.org/41x/
--2024-03-24 13:36:44--  https://redhat.cassandra.apache.org/41x/
Resolving redhat.cassandra.apache.org (redhat.cassandra.apache.org)... 35.172.124.167
Connecting to redhat.cassandra.apache.org (redhat.cassandra.apache.org)|35.172.124.167|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://apache.jfrog.io/artifactory/cassandra-rpm/41x/ [following]
--2024-03-24 13:36:45--  https://apache.jfrog.io/artifactory/cassandra-rpm/41x/
Resolving apache.jfrog.io (apache.jfrog.io)... 18.232.172.199, 18.214.194.113, 3.95.117.170
Connecting to apache.jfrog.io (apache.jfrog.io)|18.232.172.199|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://landing.jfrog.com/reactivate-server/apache [following]
--2024-03-24 13:36:46--  https://landing.jfrog.com/reactivate-server/apache
Resolving landing.jfrog.com (landing.jfrog.com)... 18.214.194.113, 3.95.117.170, 18.232.172.199
Connecting to landing.jfrog.com (landing.jfrog.com)|18.214.194.113|:443... connected.
HTTP request sent, awaiting response... 200 OK

minha cassandra.repo

[vic@ol9-135 ~]$ cat /etc/yum.repos.d/cassandra.repo
[cassandra]
name=Apache Cassandra
baseurl=https://redhat.cassandra.apache.org/41x/
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://downloads.apache.org/cassandra/KEYS
[vic@ol9-135 ~]$

Ativei Hugepages em um novo banco de dados Postgres 13, rodando em EL8 Linux (huge_pages=try), e percebi que o Shmem ainda está crescendo e nenhuma HugePages está sendo usada ainda (mas vejo que as HugePages estão configuradas). THP estão desativados.

Tentei fazer SELECT * em uma tabela grande e o shmem cresceu alguns GB, mas ainda nenhuma página enorme está sendo usada.

A última vez que configurei Hugepages em um banco de dados Postgres, acho que a mesma coisa aconteceu, mas eventualmente ele começou a usar HugePages e o uso do Shmem caiu para quase zero (presumivelmente apenas bloqueios e outros enfeites estão sendo usados ​​no Shmem).

Qual é o motivo para que páginas enormes comecem a ser usadas em vez de shmem? O que acontece internamente para orientar o comportamento/decisão?

Presumivelmente, preciso de uma operação que use páginas anônimas no Postgres, talvez SELECT * sejam todas páginas de arquivo? Eu acho que não. Existe uma consulta melhor (inofensiva, discreta, exceto com uso intensivo de RAM) para forçar o Postgres a usar um monte de páginas anon (páginas enormes)?

No postgres, estou fazendo uma consulta em 2 colunas

• string typecom apenas 3 valores possíveis
• carimbo de data/horathe_timestamp

a consulta é

select id from my_table where type = 'a-value' and the_timestamp < '2024-03-01'

1. Qual é a melhor ordem do índice para esta consulta? Acredito que existam essas sugestões, que entram em conflito
   • igualdade primeiro, intervalos depois
   • "maior cardinalidade primeiro" (apenas para correspondência, não para intervalo?)
2. Faz muita diferença se o índice em the_timestamp for descor asc, ou isso só faz diferença ao percorrer várias colunas com consultas de intervalo... ou fazer BETWEENalgo assim?

Supondo que eu tenha AG em um cluster de 4 nós, com 2 nós no site primário e 2 nós no site de DR, 1 testemunha de nuvem. O modo failover é manual.

Agora, por algum motivo, suponha que a rede do site primário caia, especificamente, não consigo me conectar ao data center primário.

Caso 1: o primário tem quorum, pois ainda é capaz de se comunicar com a testemunha da nuvem. Como há algum problema de rede no site primário, o SQL ainda está em execução no site primário e pensa que é o primário.

Caso 2: o primário não consegue se comunicar com a testemunha da nuvem e perdeu o quorum. Testemunho dinâmico e quórum dinâmico podem entrar em ação.

Suponha que agora eu me conecte a um dos nós de DR e invoque um failover manual forçado.

O SQL no site de DR pensará que é o principal, pois invoquei o failover manual. Tecnicamente, este é um cenário de cluster dividido.

O cenário de divisão no caso 1 é óbvio. No caso 2, pode ser devido ao testemunho dinâmico e ao início do quórum dinâmico.

Quando a rede primária for restabelecida, o que preciso fazer para lidar com esse cenário? Porque se o que estou pensando estiver certo, ambos os sites pensarão que possui o servidor SQL primário.

Quão rápido uma única instância física do Mysql pode executar a seguinte consulta em uma tabela de 2 colunas com cerca de 100 GB?

SELECT short_url FROM long_to_short WHERE long_url = :in_long_url

Reconheço que isso ainda deixa de fora alguns aspectos importantes - índices/configurações de banco de dados, etc. Eu realmente apreciaria uma análise pelos vários sabores.

Você sabe como isso mudaria se hierarquizássemos o armazenamento (SSD + mecânica)?

Tenho pesquisado na internet a melhor maneira de instalar o sqlplus no chip de silício da Apple MacOs (processador de bases de braço). por favor, guie-me com algum método mais fácil de fazer isso.

Eu vi muitos artigos sobre a instalação do sqlplus no processador baseado em Intel x64, mas não para o processador baseado em arm64.

Mais alguns detalhes sobre o sistema

Chip Apple M1 Pro Mac OS versão Mac OS Sonoma 14.3.1

Eu criei a seguinte consulta para obter o nome da tabela, index_type, operator_classes e exclusividade dos índices com base nas respostas principalmente de @Erwin Brandstetter:

SELECT i.indrelid::regclass::text AS table
     , c.relname AS index_name
     , a.amname AS index_type
     , opc.operator_classes
     , i.indisunique AS is_unique
     , array_agg(att.attname) as column_names
FROM   pg_catalog.pg_namespace n
JOIN   pg_catalog.pg_class     c ON c.relnamespace = n.oid
JOIN   pg_catalog.pg_attribute att ON att.attrelid = c.oid
JOIN   pg_catalog.pg_index     i ON i.indexrelid = c.oid
JOIN   pg_catalog.pg_am        a ON a.oid = c.relam
CROSS  JOIN LATERAL (
   SELECT ARRAY (SELECT opc.opcname
                 FROM   unnest(i.indclass::oid[]) WITH ORDINALITY o(oid, ord)
                 JOIN   pg_opclass opc ON opc.oid = o.oid
                 ORDER  BY o.ord)
   ) opc(operator_classes)
WHERE  n.nspname !~ '^pg_'
AND    c.relkind = ANY (ARRAY['r', 't', 'i'])
group by
   i.indrelid, c.relname, a.amname, opc.operator_classes, i.indisunique
ORDER  BY 1, 2, 3, 4;

Isso funciona muito bem, exceto que retorna nomes de colunas errados quando o índice é criado pela transformação de dados de outra coluna. Por exemplo, com o seguinte índice:

CREATE INDEX _ixtr_luxury_inventory_images ON public.luxury_inventory
 USING gin (f_textarr2text(images) gin_trgm_ops)

retorna:

table            | luxury_inventory
index_name       | _ixtr_luxury_inventory_images
index_type       | gin
operator_classes | ['gin_trgm_ops']
is_unique        | False
column_names     | ['f_textarr2text']

Obtemos f_textarr2texto nome da coluna em vez de images.

Como podemos obter os column_names corretos? Estou no Postgres 16.2, se isso importa.

Atualização: Aqui está o SQL de criação da tabela:

create table "luxury_inventory" (
id bigserial primary key,
images text[])

CREATE OR REPLACE FUNCTION "public".f_textarr2text(text[]) 
RETURNS text LANGUAGE sql IMMUTABLE AS $$SELECT array_to_string($1, ',')$$;

Um banco de dados originfoi despejado no formato “customizado” do postgres usando: pg_dump -d origin --data-only -Fc > file.dump.

O dump foi então usado para restaurar todos os dados em um banco de dados diferente com os mesmos nomes de tabela , como no originbanco de dados. Comando: pg_restore -l -d target --verbose -Fc file.dump.

;
; Archive created at 2024-03-19 14:00:10 UTC
;     dbname: origin
;     TOC Entries: 215
;     Compression: 0
;     Dump Version: 1.13-0
;     Format: CUSTOM
;     Integer: 4 bytes
;     Offset: 8 bytes
;     Dumped from database version: 11.18 (Ubuntu 11.18-1.pgdg18.04+1)
;     Dumped by pg_dump version: 11.18 (Ubuntu 11.18-1.pgdg18.04+1)
;
;
; Selected TOC Entries:
;
5357; 0 0 ENCODING - ENCODING
5358; 0 0 STDSTRINGS - STDSTRINGS
5359; 0 0 SEARCHPATH - SEARCHPATH
5360; 1262 16387 DATABASE - origin userA
5361; 0 0 DATABASE PROPERTIES - origin userA
;       depends on: 5360
5145; 0 730750 TABLE DATA subpartitions backends_y2024w03 userA
;       depends on: 237
5166; 0 738268 TABLE DATA subpartitions backends_y2024w04 userA
;       depends on: 258
5189; 0 745798 TABLE DATA subpartitions backends_y2024w05 userA
;       depends on: 281
.........

• Problema: nada foi restaurado. Conforme mostrado, parece que o dump de backup "personalizado" contém alguns depends on: xxxcomentários codificados, que não existem no banco de dados de destino. A conversão do dump em um arquivo SQL simples, contendo apenas comandos como COPY subpartitions.backends_y2024w03 ("time", dbname, data, tag_data) FROM stdin;, importou todos os dados sem problemas .

Pergunta: Como depends on: xxxas entidades ausentes são detectadas, a que se xxxrefere ao restaurar um arquivo de backup "personalizado" e como desabilitar essas verificações? (como todas as dependências reais existiam no exemplo)

Eu tenho um .NET WebApi com duas entidades (perdoe os nomes bobos, é apenas um exemplo):

public class Father
{
    public int Id { get; set; }
    public string Name { get; set; } = null!;
    public int? ChildAId { get; set; }
    public int? ChildBId { get; set; }
    public int? ChildCId { get; set; }
    public int? ChildDId { get; set; }
    public int? ChildEId { get; set; }
    public int? ChildFId { get; set; }
    public int? ChildGId { get; set; }
    public int? ChildHId { get; set; }
    public int? ChildIId { get; set; }
    public int? ChildJId { get; set; }
    public int? ChildKId { get; set; }
    public int? ChildLId { get; set; }
    public int? ChildMId { get; set; }
    public int? ChildNId { get; set; }
    public int? ChildOId { get; set; }
    public int? ChildPId { get; set; }
    public int? ChildQId { get; set; }
    public int? ChildRId { get; set; }
    public int? ChildSId { get; set; }
    public int? ChildTId { get; set; }
    public int? ChildUId { get; set; }
    public int? ChildVId { get; set; }
    public int? ChildWId { get; set; }
    public int? ChildXId { get; set; }
    public int? ChildYId { get; set; }
    public int? ChildZId { get; set; }
    public int? Child0Id { get; set; }
    public int? Child1Id { get; set; }
    public int? Child2Id { get; set; }
    public int? Child3Id { get; set; }
    public int? Child4Id { get; set; }
    public int? Child5Id { get; set; }
    public int? Child6Id { get; set; }
    public int? Child7Id { get; set; }
    public int? Child8Id { get; set; }
    public int? Child9Id { get; set; }

    public Child? ChildA { get; set; }
    public Child? ChildB { get; set; }
    public Child? ChildC { get; set; }
    public Child? ChildD { get; set; }
    public Child? ChildE { get; set; }
    public Child? ChildF { get; set; }
    public Child? ChildG { get; set; }
    public Child? ChildH { get; set; }
    public Child? ChildI { get; set; }
    public Child? ChildJ { get; set; }
    public Child? ChildK { get; set; }
    public Child? ChildL { get; set; }
    public Child? ChildM { get; set; }
    public Child? ChildN { get; set; }
    public Child? ChildO { get; set; }
    public Child? ChildP { get; set; }
    public Child? ChildQ { get; set; }
    public Child? ChildR { get; set; }
    public Child? ChildS { get; set; }
    public Child? ChildT { get; set; }
    public Child? ChildU { get; set; }
    public Child? ChildV { get; set; }
    public Child? ChildW { get; set; }
    public Child? ChildX { get; set; }
    public Child? ChildY { get; set; }
    public Child? ChildZ { get; set; }
    public Child? Child0 { get; set; }
    public Child? Child1 { get; set; }
    public Child? Child2 { get; set; }
    public Child? Child3 { get; set; }
    public Child? Child4 { get; set; }
    public Child? Child5 { get; set; }
    public Child? Child6 { get; set; }
    public Child? Child7 { get; set; }
    public Child? Child8 { get; set; }
    public Child? Child9 { get; set; }
}

public class Child
{
    public int Id { get; set; }
    public string Name { get; set; } = null!;
    public string Description { get; set; } = null!;
}

Inseri 100.000 pais com seus filhos de A a Z povoados. Agora estou tentando recuperá-los do banco de dados usando o EF Core (mas o PgAdmin dá os mesmos resultados).

20 PAIS COM LIMITE/OFFSET

SELECT f."Id", f."Child0Id", f."Child1Id", f."Child2Id", f."Child3Id", f."Child4Id", f."Child5Id", f."Child6Id", f."Child7Id", f."Child8Id", f."Child9Id", f."ChildAId", f."ChildBId", f."ChildCId", f."ChildDId", f."ChildEId", f."ChildFId", f."ChildGId", f."ChildHId", f."ChildIId", f."ChildJId", f."ChildKId", f."ChildLId", f."ChildMId", f."ChildNId", f."ChildOId", f."ChildPId", f."ChildQId", f."ChildRId", f."ChildSId", f."ChildTId", f."ChildUId", f."ChildVId", f."ChildWId", f."ChildXId", f."ChildYId", f."ChildZId", f."Name"
FROM "Father" AS f
LIMIT 20 OFFSET 98000

A consulta é concluída em 130 ms

20 PAIS COM TODOS OS SEUS FILHOS E LIMITE/COMPENSAÇÃO

  SELECT t."Id", t."Child0Id", t."Child1Id", t."Child2Id", t."Child3Id", t."Child4Id", t."Child5Id", t."Child6Id", t."Child7Id", t."Child8Id", t."Child9Id", t."ChildAId", t."ChildBId", t."ChildCId", t."ChildDId", t."ChildEId", t."ChildFId", t."ChildGId", t."ChildHId", t."ChildIId", t."ChildJId", t."ChildKId", t."ChildLId", t."ChildMId", t."ChildNId", t."ChildOId", t."ChildPId", t."ChildQId", t."ChildRId", t."ChildSId", t."ChildTId", t."ChildUId", t."ChildVId", t."ChildWId", t."ChildXId", t."ChildYId", t."ChildZId", t."Name", c."Id", c."Description", c."Name", c0."Id", c0."Description", c0."Name", c1."Id", c1."Description", c1."Name", c2."Id", c2."Description", c2."Name", c3."Id", c3."Description", c3."Name", c4."Id", c4."Description", c4."Name", c5."Id", c5."Description", c5."Name", c6."Id", c6."Description", c6."Name", c7."Id", c7."Description", c7."Name", c8."Id", c8."Description", c8."Name", c9."Id", c9."Description", c9."Name", c10."Id", c10."Description", c10."Name", c11."Id", c11."Description", c11."Name", c12."Id", c12."Description", c12."Name", c13."Id", c13."Description", c13."Name", c14."Id", c14."Description", c14."Name", c15."Id", c15."Description", c15."Name", c16."Id", c16."Description", c16."Name", c17."Id", c17."Description", c17."Name", c18."Id", c18."Description", c18."Name", c19."Id", c19."Description", c19."Name", c20."Id", c20."Description", c20."Name", c21."Id", c21."Description", c21."Name", c22."Id", c22."Description", c22."Name", c23."Id", c23."Description", c23."Name", c24."Id", c24."Description", c24."Name", c25."Id", c25."Description", c25."Name", c26."Id", c26."Description", c26."Name", c27."Id", c27."Description", c27."Name", c28."Id", c28."Description", c28."Name", c29."Id", c29."Description", c29."Name", c30."Id", c30."Description", c30."Name", c31."Id", c31."Description", c31."Name", c32."Id", c32."Description", c32."Name", c33."Id", c33."Description", c33."Name", c34."Id", c34."Description", c34."Name"
  FROM (
      SELECT f."Id", f."Child0Id", f."Child1Id", f."Child2Id", f."Child3Id", f."Child4Id", f."Child5Id", f."Child6Id", f."Child7Id", f."Child8Id", f."Child9Id", f."ChildAId", f."ChildBId", f."ChildCId", f."ChildDId", f."ChildEId", f."ChildFId", f."ChildGId", f."ChildHId", f."ChildIId", f."ChildJId", f."ChildKId", f."ChildLId", f."ChildMId", f."ChildNId", f."ChildOId", f."ChildPId", f."ChildQId", f."ChildRId", f."ChildSId", f."ChildTId", f."ChildUId", f."ChildVId", f."ChildWId", f."ChildXId", f."ChildYId", f."ChildZId", f."Name"
      FROM "Father" AS f
      LIMIT 20 OFFSET 98000
  ) AS t
  LEFT JOIN "Child" AS c ON t."ChildAId" = c."Id"
  LEFT JOIN "Child" AS c0 ON t."ChildBId" = c0."Id"
  LEFT JOIN "Child" AS c1 ON t."ChildCId" = c1."Id"
  LEFT JOIN "Child" AS c2 ON t."ChildDId" = c2."Id"
  LEFT JOIN "Child" AS c3 ON t."ChildEId" = c3."Id"
  LEFT JOIN "Child" AS c4 ON t."ChildFId" = c4."Id"
  LEFT JOIN "Child" AS c5 ON t."ChildGId" = c5."Id"
  LEFT JOIN "Child" AS c6 ON t."ChildHId" = c6."Id"
  LEFT JOIN "Child" AS c7 ON t."ChildIId" = c7."Id"
  LEFT JOIN "Child" AS c8 ON t."ChildJId" = c8."Id"
  LEFT JOIN "Child" AS c9 ON t."ChildKId" = c9."Id"
  LEFT JOIN "Child" AS c10 ON t."ChildLId" = c10."Id"
  LEFT JOIN "Child" AS c11 ON t."ChildMId" = c11."Id"
  LEFT JOIN "Child" AS c12 ON t."ChildNId" = c12."Id"
  LEFT JOIN "Child" AS c13 ON t."ChildOId" = c13."Id"
  LEFT JOIN "Child" AS c14 ON t."ChildPId" = c14."Id"
  LEFT JOIN "Child" AS c15 ON t."ChildQId" = c15."Id"
  LEFT JOIN "Child" AS c16 ON t."ChildRId" = c16."Id"
  LEFT JOIN "Child" AS c17 ON t."ChildSId" = c17."Id"
  LEFT JOIN "Child" AS c18 ON t."ChildTId" = c18."Id"
  LEFT JOIN "Child" AS c19 ON t."ChildUId" = c19."Id"
  LEFT JOIN "Child" AS c20 ON t."ChildVId" = c20."Id"
  LEFT JOIN "Child" AS c21 ON t."ChildWId" = c21."Id"
  LEFT JOIN "Child" AS c22 ON t."ChildXId" = c22."Id"
  LEFT JOIN "Child" AS c23 ON t."ChildYId" = c23."Id"
  LEFT JOIN "Child" AS c24 ON t."ChildZId" = c24."Id"
  LEFT JOIN "Child" AS c25 ON t."Child0Id" = c25."Id"
  LEFT JOIN "Child" AS c26 ON t."Child1Id" = c26."Id"
  LEFT JOIN "Child" AS c27 ON t."Child2Id" = c27."Id"
  LEFT JOIN "Child" AS c28 ON t."Child3Id" = c28."Id"
  LEFT JOIN "Child" AS c29 ON t."Child4Id" = c29."Id"
  LEFT JOIN "Child" AS c30 ON t."Child5Id" = c30."Id"
  LEFT JOIN "Child" AS c31 ON t."Child6Id" = c31."Id"
  LEFT JOIN "Child" AS c32 ON t."Child7Id" = c32."Id"
  LEFT JOIN "Child" AS c33 ON t."Child8Id" = c33."Id"
  LEFT JOIN "Child" AS c34 ON t."Child9Id" = c34."Id"

A consulta é concluída em 300 ms

PAI SOLTEIRO POR ID (COM LIMITE DEFINIDO POR SINGLEORDEFAULT)

SELECT f."Id", f."Child0Id", f."Child1Id", f."Child2Id", f."Child3Id", f."Child4Id", f."Child5Id", f."Child6Id", f."Child7Id", f."Child8Id", f."Child9Id", f."ChildAId", f."ChildBId", f."ChildCId", f."ChildDId", f."ChildEId", f."ChildFId", f."ChildGId", f."ChildHId", f."ChildIId", f."ChildJId", f."ChildKId", f."ChildLId", f."ChildMId", f."ChildNId", f."ChildOId", f."ChildPId", f."ChildQId", f."ChildRId", f."ChildSId", f."ChildTId", f."ChildUId", f."ChildVId", f."ChildWId", f."ChildXId", f."ChildYId", f."ChildZId", f."Name"
      FROM "Father" AS f
      WHERE f."Id" = 1
      LIMIT 2

A consulta é concluída em 115 ms

AGORA VEM O PROBLEMA: PAI SOLTEIRO COM TODOS OS FILHOS POR BI (COM LIMITE DEFINIDO POR SINGLEORDEFAULT)

  SELECT f."Id", f."Child0Id", f."Child1Id", f."Child2Id", f."Child3Id", f."Child4Id", f."Child5Id", f."Child6Id", f."Child7Id", f."Child8Id", f."Child9Id", f."ChildAId", f."ChildBId", f."ChildCId", f."ChildDId", f."ChildEId", f."ChildFId", f."ChildGId", f."ChildHId", f."ChildIId", f."ChildJId", f."ChildKId", f."ChildLId", f."ChildMId", f."ChildNId", f."ChildOId", f."ChildPId", f."ChildQId", f."ChildRId", f."ChildSId", f."ChildTId", f."ChildUId", f."ChildVId", f."ChildWId", f."ChildXId", f."ChildYId", f."ChildZId", f."Name", c."Id", c."Description", c."Name", c0."Id", c0."Description", c0."Name", c1."Id", c1."Description", c1."Name", c2."Id", c2."Description", c2."Name", c3."Id", c3."Description", c3."Name", c4."Id", c4."Description", c4."Name", c5."Id", c5."Description", c5."Name", c6."Id", c6."Description", c6."Name", c7."Id", c7."Description", c7."Name", c8."Id", c8."Description", c8."Name", c9."Id", c9."Description", c9."Name", c10."Id", c10."Description", c10."Name", c11."Id", c11."Description", c11."Name", c12."Id", c12."Description", c12."Name", c13."Id", c13."Description", c13."Name", c14."Id", c14."Description", c14."Name", c15."Id", c15."Description", c15."Name", c16."Id", c16."Description", c16."Name", c17."Id", c17."Description", c17."Name", c18."Id", c18."Description", c18."Name", c19."Id", c19."Description", c19."Name", c20."Id", c20."Description", c20."Name", c21."Id", c21."Description", c21."Name", c22."Id", c22."Description", c22."Name", c23."Id", c23."Description", c23."Name", c24."Id", c24."Description", c24."Name", c25."Id", c25."Description", c25."Name", c26."Id", c26."Description", c26."Name", c27."Id", c27."Description", c27."Name", c28."Id", c28."Description", c28."Name", c29."Id", c29."Description", c29."Name", c30."Id", c30."Description", c30."Name", c31."Id", c31."Description", c31."Name", c32."Id", c32."Description", c32."Name", c33."Id", c33."Description", c33."Name", c34."Id", c34."Description", c34."Name"
  FROM "Father" AS f
  LEFT JOIN "Child" AS c ON f."ChildAId" = c."Id"
  LEFT JOIN "Child" AS c0 ON f."ChildBId" = c0."Id"
  LEFT JOIN "Child" AS c1 ON f."ChildCId" = c1."Id"
  LEFT JOIN "Child" AS c2 ON f."ChildDId" = c2."Id"
  LEFT JOIN "Child" AS c3 ON f."ChildEId" = c3."Id"
  LEFT JOIN "Child" AS c4 ON f."ChildFId" = c4."Id"
  LEFT JOIN "Child" AS c5 ON f."ChildGId" = c5."Id"
  LEFT JOIN "Child" AS c6 ON f."ChildHId" = c6."Id"
  LEFT JOIN "Child" AS c7 ON f."ChildIId" = c7."Id"
  LEFT JOIN "Child" AS c8 ON f."ChildJId" = c8."Id"
  LEFT JOIN "Child" AS c9 ON f."ChildKId" = c9."Id"
  LEFT JOIN "Child" AS c10 ON f."ChildLId" = c10."Id"
  LEFT JOIN "Child" AS c11 ON f."ChildMId" = c11."Id"
  LEFT JOIN "Child" AS c12 ON f."ChildNId" = c12."Id"
  LEFT JOIN "Child" AS c13 ON f."ChildOId" = c13."Id"
  LEFT JOIN "Child" AS c14 ON f."ChildPId" = c14."Id"
  LEFT JOIN "Child" AS c15 ON f."ChildQId" = c15."Id"
  LEFT JOIN "Child" AS c16 ON f."ChildRId" = c16."Id"
  LEFT JOIN "Child" AS c17 ON f."ChildSId" = c17."Id"
  LEFT JOIN "Child" AS c18 ON f."ChildTId" = c18."Id"
  LEFT JOIN "Child" AS c19 ON f."ChildUId" = c19."Id"
  LEFT JOIN "Child" AS c20 ON f."ChildVId" = c20."Id"
  LEFT JOIN "Child" AS c21 ON f."ChildWId" = c21."Id"
  LEFT JOIN "Child" AS c22 ON f."ChildXId" = c22."Id"
  LEFT JOIN "Child" AS c23 ON f."ChildYId" = c23."Id"
  LEFT JOIN "Child" AS c24 ON f."ChildZId" = c24."Id"
  LEFT JOIN "Child" AS c25 ON f."Child0Id" = c25."Id"
  LEFT JOIN "Child" AS c26 ON f."Child1Id" = c26."Id"
  LEFT JOIN "Child" AS c27 ON f."Child2Id" = c27."Id"
  LEFT JOIN "Child" AS c28 ON f."Child3Id" = c28."Id"
  LEFT JOIN "Child" AS c29 ON f."Child4Id" = c29."Id"
  LEFT JOIN "Child" AS c30 ON f."Child5Id" = c30."Id"
  LEFT JOIN "Child" AS c31 ON f."Child6Id" = c31."Id"
  LEFT JOIN "Child" AS c32 ON f."Child7Id" = c32."Id"
  LEFT JOIN "Child" AS c33 ON f."Child8Id" = c33."Id"
  LEFT JOIN "Child" AS c34 ON f."Child9Id" = c34."Id"
  WHERE f."Id" = 1
  LIMIT 2

A consulta é concluída em MAIS DE DOIS SEGUNDOS! 2300ms

Alguém pode me explicar por que e como otimizar essa consulta? Tenho índices em todos os PKs e FKs.

Tenho um banco de dados postgresql configurado com pgbackrest para backups. Ele retém backups completos por 7 dias:

[global]
repo1-retention-full-type=time
repo1-retention-full=7

Configurei o cron para criar um backup completo no domingo com backups incrementais todos os dias. Isso funciona conforme o esperado e remove backups completos depois que o mais recente tiver mais de 7 dias. O crontab real chama um script que usa os comandos pgbackrest, mas para simplificar:

0 0 * * 0   root    pgbackrest --type=full backup
0 0 * * 1-6 root    pgbackrest backup

Estou procurando configurar o pgbackrest para criar backups completos automaticamente a cada 7 dias, então precisaria apenas de um cron job:

0 0 * * *   root    pgbackrest backup

Isso é possível ou terei que escrever alguma lógica bash no meu script?