Gonzalo Vasquez's questions

Como parte de um sistema de relatórios automatizados diários, executamos uma série de consultas para verificar diferentes parâmetros operacionais das tabelas de ativos de nossos clientes.

Na terça-feira passada adicionei uma nova verificação que funciona, mas acionei alguns alarmes de desempenho que me levaram a analisar o que poderia estar errado e acabei percebendo que a nova verificação na verdade aumentou o tempo geral das verificações em cerca de 160%.

Aprofundando essa nova verificação, reduzi-a à consulta de banco de dados real que está afetando todo o processo:

select case COALESCE(max(driverid),-1) when 0 then false when -1 then null else true end 
from reports.avl_historico_354676052451142 
where DATE_PART('day', now() - fecha ) < 5;

E ao fazer um explain analyze verbose, recebo:

Aggregate  (cost=75004.56..75004.58 rows=1 width=4) (actual time=544.460..544.461 rows=1 loops=1)
  Output: CASE COALESCE(max(driverid), (-1)) WHEN 0 THEN false WHEN (-1) THEN NULL::boolean ELSE true END
  ->  Seq Scan on reports.avl_historico_354676052451142  (cost=0.00..73782.38 rows=488873 width=4) (actual time=535.565..541.467 rows=9661 loops=1)
        Output: fecha, latitud, longitud, altitud, velocidad, cog, nsat, tipo, utc_hora, fix_fecha, imei, registro, input1, input2, input3, input4, hdop, adc, ignicion, adc2, power, driverid, ibutton2, ibutton3, ibutton4, trailerid, adc3, adc4, horometro, odometro, panico, bateria, bateriaint
        Filter: (date_part('day'::text, (now() - avl_historico_354676052451142.fecha)) < 5::double precision)
        Rows Removed by Filter: 1457143
Planning time: 0.078 ms
Execution time: 544.582 ms

Então, estou supondo que essa consulta pode precisar de algum tipo de ajuda / melhoria, mas estou completamente sem noção sobre isso. Então eu estou perguntando: quais melhorias você recomendaria para este cenário? Índices? Reformulação da consulta? Outros? O que mais devo fornecer para uma compreensão mais profunda do modelo?

Por favor, considere que a tabela de amostra na consulta tem um número grande em seu nome, que significa um deviceId e temos cerca de 30k tabelas daquelas que são consultadas regularmente... é algum tipo de modelo de particionamento de tabela.

Atualizar!

Novos resultados da indexação sugerida por @a_horse_with_no_name :

Aggregate  (cost=5478.72..5478.74 rows=1 width=4) (actual time=8.302..8.302 rows=1 loops=1)
  Output: CASE COALESCE(max(driverid), (-1)) WHEN 0 THEN false WHEN (-1) THEN NULL::boolean ELSE true END
  ->  Index Scan using reports_avl_historico_354676052451142_index_fecha on reports.avl_historico_354676052451142  (cost=0.43..5473.68 rows=2017 width=4) (actual time=0.026..4.644 rows=12249 loops=1)
        Output: fecha, latitud, longitud, altitud, velocidad, cog, nsat, tipo, utc_hora, fix_fecha, imei, registro, input1, input2, input3, input4, hdop, adc, ignicion, adc2, power, driverid, ibutton2, ibutton3, ibutton4, trailerid, adc3, adc4, horometro, odometro, panico, bateria, bateriaint
        Index Cond: (avl_historico_354676052451142.fecha > (('now'::cstring)::date - 5))
Planning time: 0.181 ms
Execution time: 8.332 ms

Vou cronometrar a execução geral e mantê-lo informado.

Esta deve ser uma das perguntas mais idiotas que já fiz aqui, mas deve haver algo realmente doente escondido no meu script SQL que está bloqueando sua execução.

Estou invocando o arquivo cobertura.sql usando a seguinte sintaxe de amostra da CLI:

psql -h localhost -U myUser -f cobertura.sql myDB

Mas reclama com o seguinte erro:

psql:cobertura.sql:29: ERROR:  "sql " is not a known variable
LINE 14: sql := format('insert into cobertura_tmp select count(*) as ... cobertura.sql file:

DO language plpgsql $$
declare 
    eq  record;
    sql varchar;
BEGIN

create table if not exists cobertura_tmp  (num integer, realtime char(1), lat numeric, lng numeric);

truncate table cobertura_tmp;
for eq in select imei_equipo as imei  from cliente_avl_equipo where id_cliente in (select id from cliente where nombre ilike '%enangab%') limit 3

loop

sql := format('insert into cobertura_tmp select count(*) as num, tipo as realtime, round(CAST(latitud as numeric), 4) as lat ,round(CAST(longitud as numeric), 4) as lng   from reports.avl_historico_%s where latitud between -38.67405472 and -36.75131149 and longitud between  -73.08429161 and -69.65333954 group by tipo, round(CAST(latitud as numeric), 4),round(CAST(longitud as numeric), 4)', eq.imei);

execute sql;

end loop;

update cobertura_tmp set num= -1* num where realtime='S';

create table if not exists cobertura_tmp_resumen  (num integer, lat numeric, lng numeric);
truncate cobertura_tmp_resumen;
--    select sum(num) as num , lat, lng into cobertura_tmp_resumen from cobertura_tmp group by lat,lng;

--    drop table if exists cobertura_tmp;

END;
$$;

O mesmo script é executado remotamente e sem problemas no Mac OSX usando o Postico Versão 1.3.2 (2318).

PERGUNTA: Por que não está encontrando a sqlvariável que está na declareseção?

Estou construindo um wrapper para acesso ao banco de dados usando as funções Java do Lambda da AWS , o problema que estou tendo é que os parâmetros do Lambda são JSON, portanto, sem tipo, portanto, todos os parâmetros de entrada são de-JSON em Strings e, ao adicioná-los a um PreparedStatement usando o método setObject (param, value) todos eles são tratados como se você estivesse usando setString (param, value), isso é bom para Strings e números, mas quando se trata de um parâmetro que é um carimbo de data e hora, nós obtenha uma incompatibilidade de tipo de parâmetro como esta:

org.postgresql.util.PSQLException: operator does not exist: timestamp with time zone >= character varying
Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts.

Estou ciente de que passar tipos de parâmetro como um campo extra para o JSON pode ajudar, mas estou preocupado com a sobrecarga extra e a necessidade de adicionar manualmente o tipo de parâmetro ao JSON, pois está sendo construído "automagicamente" do DTO subjacente usando GSON .

Alguém pode descobrir uma abordagem diferente, talvez passando os parâmetros para o PreparedStatement.?

Temos um servidor de produção PostgreSQL 9.4.9 que estava replicando para uma instância escrava, mas hoje descobri que a instância está fora de sincronia!

As ações óbvias seriam recriar o escravo, configurar métricas e alarmes adequados para a atividade de replicação, para que possamos monitorar efetivamente o status de sincronização entre os nós mestre e escravo.

Mas, como a sincronização falhou, gostaria de primeiro diagnosticar o problema e tentar identificar a causa raiz dele, pois esta seria a segunda vez que isso acontece em cerca de 6 meses.

Pergunta : Como diagnosticar o que falhou no processo de replicação para que possa ser feito da melhor forma desta vez?

Especificações da versão:

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

Do nó escravo, em /var/log/postgresql/postgresql-9.4-main.logposso ver:

2017-07-18 19:43:55 UTC [12816-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:43:55 UTC [12816-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:00 UTC [12817-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:00 UTC [12817-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:05 UTC [12821-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:05 UTC [12821-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:10 UTC [12825-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:10 UTC [12825-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:15 UTC [12826-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:15 UTC [12826-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

Nova pergunta : Como posso ver para trás onde o problema real apareceu?

Mestre postgresql.conf: https://pastebin.com/NJX5ku6m

Escravo postgresql.conf: https://pastebin.com/CUZcyazC

Escravo recovery.conf:

standby_mode = on
primary_conninfo = 'host=10.1.1.65 port=5432 user=replicador password=replicador'

Existem dicas, estatísticas ou similares disponíveis para verificar minuciosamente quais índices podem ser excluídos com segurança de um banco de dados PostgreSQL 9.4.9? Nosso banco de dados continua crescendo e crescendo e achamos que pode haver alguma perda em índices que não estão sendo usados. No passado, tentamos reduzir o tamanho geral do banco de dados (cerca de 2 TB agora, principalmente dados históricos), mas os clientes continuavam precisando de acesso a dados antigos, então tivemos que parar de expirar dados antigos "supostamente não utilizados" porque trazê-los de volta ao vivo, foi uma dor enorme.

Quaisquer comentários adicionais sobre a economia de espaço seriam muito apreciados.

Existe algum tipo de consulta/visualização/tabela disponível no PostgreSQL que possa refletir o status real de um processo de replicação mestre-escravo? Talvez o "grau" de sincronização entre os nós?

O acima é para monitorar periodicamente nossos servidores para garantir que eles estejam realmente "sincronizados" e que o escravo não tenha ficado à deriva.

Atualmente, tenho um nó escravo do PostgreSQL que está apresentando problemas, que não surgem no nó mestre. Parece estar relacionado com o processo de sincronização do nó.

Rastreamento de pilha completo:

org.postgresql.util.PSQLException: ERROR: canceling statement due to conflict with recovery
  Detail: User query might have needed to see row versions that must be removed.
    at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103)
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:388)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:273)
    at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
    at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
    at cl.waypoint.mailer.reportes.BasicReport.getSingleColumn(BasicReport.java:542)
    at cl.waypoint.mailer.reportes.BasicReport.getSingleColumn(BasicReport.java:518)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes.updateIgnicion(StatusSemanalClientes.java:448)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes.access$2(StatusSemanalClientes.java:447)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes$TempAndDoorLocator.call(StatusSemanalClientes.java:414)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes$TempAndDoorLocator.call(StatusSemanalClientes.java:1)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

Versão do banco de dados:

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

Versão do sistema operacional:

Distributor ID: Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:   jessie

A questão é: como posso depurar a causa real do problema e/ou resolvê-lo/evitá-lo? Não hesite em pedir mais informações, se necessário, para identificar o problema, agora não sei mais o que fornecer.

PS: O erro NÃO aparece se a consulta incorreta for repetida, portanto, não está estritamente relacionado à consulta em si, mas talvez com um transiente de atualização/sincronização de tabela.

Eu tenho uma tabela com (suponha) apenas 2 colunas:

- fecha (a date)
- ignicion (0/1 representing boolean state)

O objetivo é recuperar quais períodos de tempo a ignição foi mantida em '1', para tal tarefa, descobri uma abordagem iterativa como a das seguintes consultas:

select min(fecha) from reports.avl_historico_11557000631206 where ignicion=1  and fecha > '2016-05-11 00:00:00-03' and fecha < '2016-05-12 00:00:00-03'; 

select min(fecha) from reports.avl_historico_11557000631206 where ignicion=0  and fecha > '2016-05-11 03:01:38+00' and fecha < '2016-05-12 00:00:00-03';

select min(fecha) from reports.avl_historico_11557000631206 where ignicion=1  and fecha > '2016-05-11 03:42:19+00' and fecha < '2016-05-12 00:00:00-03';

Programar isso não é problema, mas executá-lo pode ser um problema, já que o relatório pode envolver um mês inteiro de dados, e não apenas de uma única tabela sendo "varrida", mas cerca de 500 com a mesma estrutura de dados (apenas nomes de tabelas diferentes ).

Alguma ideia de como isso poderia ser alcançado de uma maneira mais limpa/melhor/rápida?

Fui aconselhado sobre as funções " janela ", mas realmente não sei se alguma delas realmente se encaixa nessa tarefa.

É possível auditar um banco de dados Postgresql 9.4.5 de forma que eu possa descobrir quando um registro específico foi excluído? Não sei o que preciso ter habilitado/disponível para tal

Estou usando a seguinte consulta para encontrar índices não utilizados:

SELECT 
PSUI.indexrelid::regclass AS IndexName 
,PSUI.relid::regclass AS TableName 
FROM pg_stat_user_indexes AS PSUI 
JOIN pg_index AS PI 
ON PSUI.IndexRelid = PI.IndexRelid 
WHERE PSUI.idx_scan = 0 
AND PI.indisunique IS FALSE;

Devo executar qualquer sintaxe de coleta de estatísticas ou qualquer outra coisa antes de executá-lo? A consulta acima é adequada para esse propósito? Quer dizer, então todos os índices mostrados na saída SQL devem ser apenas excluídos?

É um BD de 8 anos, então as linhas resultantes podem ser realmente sobras e, acho que deve haver estatísticas suficientes, então diga onde e se é usado ou não.

No processo de encontrar índices duplicados, tenho usado a seguinte consulta para identificá-los:

SELECT 
indrelid::regclass AS TableName 
,array_agg(indexrelid::regclass) AS Indexes 
FROM pg_index 
GROUP BY 
indrelid 
,indkey 
HAVING COUNT(*) > 1;

De onde obtenho uma entrada com os seguintes dados:

tablename   indexes
distribucion.asignacion {distribucion.distribucion_unique_asignacion_imei,distribucion.pk_distribucion_asignacion}

Também verifique se o índice está realmente duplicado, vejo manualmente as colunas envolvendo cada índice relatado, com esta consulta:

select * from pg_indexes where tablename='<table_name>';

Mas quando procuro os índices acima para a tabela ''distribucion.asignacion'', não obtenho resultados.

O que pode estar errado? Esses índices foram deixados "órfãos", em caso afirmativo, pode haver outras estruturas órfãs também em meu banco de dados, então como posso encontrá-las?

Nosso ambiente de produção congelou* esta manhã por um tempo ao alterar uma tabela, adicionando uma coluna na verdade.

SQL ofensivo:ALTER TABLE cliente ADD COLUMN topicos character varying(20)[];

* O login em nosso sistema requer uma seleção dessa mesma tabela, para que ninguém possa fazer login durante a alteração da tabela. Na verdade, tivemos que encerrar o processo para permitir que o sistema retomasse as operações normais.

Estrutura da tabela:

CREATE TABLE cliente
(
  rut character varying(30) NOT NULL,
  nombre character varying(150) NOT NULL,
  razon_social character varying(150) NOT NULL,
  direccion character varying(200) NOT NULL,
  comuna character varying(100) NOT NULL,
  ciudad character varying(100) NOT NULL,
  codigo_pais character varying(3) NOT NULL,
  activo boolean DEFAULT true,
  id serial NOT NULL,
  stock boolean DEFAULT false,
  vigente boolean DEFAULT true,
  clase integer DEFAULT 1,
  plan integer DEFAULT 1,
  plantilla character varying(15) DEFAULT 'WAYPOINT'::character varying,
  facturable integer DEFAULT 1,
  toolkit integer DEFAULT 0,
  propietario integer DEFAULT 0,
  creacion timestamp without time zone DEFAULT now(),
  codelco boolean NOT NULL DEFAULT false,
  familia integer DEFAULT 0,
  enabled_machines boolean DEFAULT false,
  enabled_canbus boolean DEFAULT false,
  enabled_horometro boolean DEFAULT false,
  enabled_comap boolean DEFAULT false,
  enabled_frio boolean DEFAULT false,
  enabled_panico boolean DEFAULT false,
  enabled_puerta boolean DEFAULT false,
  enabled_rpm boolean DEFAULT false,
  enabled_supervisor integer DEFAULT 0,
  demo boolean,
  interno boolean,
  mqtt_enable boolean NOT NULL DEFAULT false,
  topicos character varying(20)[],
  CONSTRAINT pk_cliente PRIMARY KEY (rut),
  CONSTRAINT fk_cliente_familiaid FOREIGN KEY (familia)
      REFERENCES cliente_familia (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT pk_pais FOREIGN KEY (codigo_pais)
      REFERENCES pais (codigo) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT unique_id_cliente UNIQUE (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE cliente
  OWNER TO waypoint;
GRANT ALL ON TABLE cliente TO waypoint;
GRANT ALL ON TABLE cliente TO waypointtx;
GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE cliente TO waypointtomcat;
GRANT SELECT ON TABLE cliente TO waypointphp;
GRANT SELECT ON TABLE cliente TO waypointpphppublic;
GRANT ALL ON TABLE cliente TO waypointsoporte;
GRANT SELECT, INSERT ON TABLE cliente TO waypointsalesforce;
GRANT SELECT ON TABLE cliente TO waypointadminuser;
GRANT SELECT ON TABLE cliente TO waypointagenda;
GRANT SELECT ON TABLE cliente TO waypointmachines;
GRANT SELECT ON TABLE cliente TO waypointreports;
GRANT SELECT ON TABLE cliente TO readonly;

CREATE INDEX index_cliente
  ON cliente
  USING btree
  (rut COLLATE pg_catalog."default");

CREATE INDEX index_cliente_activo
  ON cliente
  USING btree
  (activo);

CREATE INDEX index_cliente_id_activo
  ON cliente
  USING btree
  (id, activo);

CREATE INDEX index_cliente_rut_activo
  ON cliente
  USING btree
  (rut COLLATE pg_catalog."default", activo);


CREATE TRIGGER trigger_default_admin
  AFTER INSERT
  ON cliente
  FOR EACH ROW
  EXECUTE PROCEDURE crea_default_admin();

CREATE TRIGGER trigger_default_grupo
  AFTER INSERT
  ON cliente
  FOR EACH ROW
  EXECUTE PROCEDURE crea_default_clientegrupo();  

Devo desabilitar CONSTRAINTS, TRIGGERS ou algo mais?

Talvez algum DB Tuning?

O que mais devo fornecer para uma análise mais aprofundada?

Versão: PostgreSQL 9.4.5 em x86_64-unknown-linux-gnu, compilado por gcc (Debian 4.9.2-10) 4.9.2, 64 bits

Temos um banco de dados bastante grande (cerca de 700 GB de dados), que foi herdado para nós e teve vários DBAs. Com o tempo percebemos que faltam várias chaves estrangeiras e índices.

Gostaria de saber se existe alguma maneira automatizada de descobrir essas possíveis chaves/índices ausentes usando algum tipo de análise de log ou algo semelhante.

Preciso fazer um OUTER JOIN em duas tabelas, baseado em 2 colunas, primeiro id um INTEGER id, que é bem simples de usar na consulta, mas o segundo é um DATETIME, que na verdade não corresponde a um valor na tabela outra tabela, mas precisa "combinar" a data mais próxima.

Como um bônus adicional ao problema, na tabela de referência, os dados não são como DATETIME, mas em duas colunas separadas: uma DATE e outra TIME.

Essa pergunta é derivada de outras duas que já fiz antes, mas como preciso restringir os problemas, preferi fazer perguntas separadas.

A questão é como escolher a data mais próxima em uma abordagem de melhor desempenho. Eu tentei usar entre (tolerância de 1 minuto) e coisas assim, mas a consulta demora muito e o plano de explicação fornece muitas linhas nas tabelas envolvidas.

Talvez algo como usar subconsultas possa funcionar mais rápido, mas simplesmente não sei como criá-los para a sintaxe JOIN.

Referências:

1. Junte-se à mesa "pobre"
2. Consulta de junção com diferentes tipos de coluna na parte "on"

BD: MySQL 5.5.43-0+deb8u1-log

Precisa fazer um JOIN em 2 tabelas com base em colunas que possuem diferentes tipos de coluna.

Na tabela A, tenho um campo DATETIME e, na tabela B, tenho um campo DATE e um campo TIME, que combinados corresponderiam ao campo DATETIME da tabela A.

Qual seria a sintaxe recomendada para melhor desempenho em tal cláusula de junção?

BD: MySQL 5.5.43-0+deb8u1-log

PD: Alguma informação extra necessária?

A partir do seguinte plano de explicação:

explain SELECT imei, cliente_avl_equipo.id_cliente AS idcliente,
               cliente_avl_vehiculo.grupo AS grupo, avl_vehiculo.id,
               avl_vehiculo.id_clase, avl_vehiculo_clase.icono AS icono,
               avl_vehiculo.descripcion, avl_vehiculo.patente,
               avl_vehiculo.info, avl_vehiculo.conductor,
               avl_vehiculo.fijo_chasis, avl_vehiculo.enabled
        FROM   cliente_avl_vehiculo,avl_vehiculo, avl_vehiculo_equipo,
               cliente_avl_equipo, avl_vehiculo_clase
        WHERE  avl_vehiculo.id                 =avl_vehiculo_equipo.id
        AND    cliente_avl_vehiculo.vehiculo_id=avl_vehiculo.id
        AND    cliente_avl_equipo.imei_equipo  =avl_vehiculo_equipo.imei
        AND    avl_vehiculo_clase.id           =avl_vehiculo.id_clase
        AND    avl_vehiculo_equipo.imei        =1234

Eu recebo uma saída como esta:

Nested Loop  (cost=0.00..22.57 rows=1 width=125
    ->  Nested Loop  (cost=0.00..22.29 rows=1 width=67)
        ->  Nested Loop  (cost=0.00..14.92 rows=1 width=63)
          ->  Nested Loop  (cost=0.00..14.58 rows=1 width=63)
                ->  Index Scan using fki_avl_vehiculo_equipo_imei on avl_vehiculo_equipo  (cost=0.00..7.28 rows=1 width=12)
                      Index Cond: (imei = 1234)
                ->  Index Scan using index_avl_vehiculo_id on avl_vehiculo  (cost=0.00..7.29 rows=1 width=51)
                      Index Cond: (id = avl_vehiculo_equipo.id)
          ->  Index Scan using index_cliente_avl_vehiculo_id on cliente_avl_vehiculo  (cost=0.00..0.33 rows=1 width=8)
               Index Cond: (vehiculo_id = avl_vehiculo.id)
       ->  Index Scan using fki_cliente_avl_equipo_imei on cliente_avl_equipo  (cost=0.00..7.36 rows=1 width=12)
              Index Cond: (imei_equipo = 1234)
    ->  Index Scan using index_avl_vehiculo_clase_id on avl_vehiculo_clase  (cost=0.00..0.27 rows=1 width=62)
        Index Cond: (id = avl_vehiculo.id_clase)

Não estou muito familiarizado com as saídas explicativas, mas as Index Scanlinhas parecem boas para mim, mas estou em dúvida com Nested Loopelas, qualquer conselho seria apreciado.

Saída adicionada explain(analyze, verbose, buffers)conforme solicitado por @a_horse_with_no_name:

Nested Loop  (cost=0.00..22.57 rows=1 width=125) (actual time=0.122..0.122 rows=0 loops=1)
  Output: avl_vehiculo_equipo.imei, cliente_avl_equipo.id_cliente, cliente_avl_vehiculo.grupo, avl_vehiculo.id, avl_vehiculo.id_clase, avl_vehiculo_clase.icono, avl_vehiculo.descripcion, avl_vehiculo.patente, avl_vehiculo.info, avl_vehiculo.conductor, avl_ (...)
  Buffers: shared hit=6
  ->  Nested Loop  (cost=0.00..22.29 rows=1 width=67) (actual time=0.121..0.121 rows=0 loops=1)
        Output: cliente_avl_vehiculo.grupo, avl_vehiculo.id, avl_vehiculo.id_clase, avl_vehiculo.descripcion, avl_vehiculo.patente, avl_vehiculo.info, avl_vehiculo.conductor, avl_vehiculo.fijo_chasis, avl_vehiculo.enabled, avl_vehiculo_equipo.imei, cliente (...)
        Buffers: shared hit=6
        ->  Nested Loop  (cost=0.00..14.92 rows=1 width=63) (actual time=0.120..0.120 rows=0 loops=1)
              Output: cliente_avl_vehiculo.grupo, avl_vehiculo.id, avl_vehiculo.id_clase, avl_vehiculo.descripcion, avl_vehiculo.patente, avl_vehiculo.info, avl_vehiculo.conductor, avl_vehiculo.fijo_chasis, avl_vehiculo.enabled, avl_vehiculo_equipo.imei
              Buffers: shared hit=6
              ->  Nested Loop  (cost=0.00..14.58 rows=1 width=63) (actual time=0.119..0.119 rows=0 loops=1)
                    Output: avl_vehiculo.id, avl_vehiculo.id_clase, avl_vehiculo.descripcion, avl_vehiculo.patente, avl_vehiculo.info, avl_vehiculo.conductor, avl_vehiculo.fijo_chasis, avl_vehiculo.enabled, avl_vehiculo_equipo.imei, avl_vehiculo_equipo.id
                    Buffers: shared hit=6
                    ->  Index Scan using fki_avl_vehiculo_equipo_imei on public.avl_vehiculo_equipo  (cost=0.00..7.28 rows=1 width=12) (actual time=0.118..0.118 rows=0 loops=1)
                          Output: avl_vehiculo_equipo.imei, avl_vehiculo_equipo.id, avl_vehiculo_equipo.movil, avl_vehiculo_equipo.creation, avl_vehiculo_equipo.updated, avl_vehiculo_equipo.power_input, avl_vehiculo_equipo.ign_input, avl_vehiculo_equipo.po (...)
                          Index Cond: (avl_vehiculo_equipo.imei = 1234)
                          Buffers: shared hit=6
                    ->  Index Scan using index_avl_vehiculo_id on public.avl_vehiculo  (cost=0.00..7.29 rows=1 width=51) (never executed)
                          Output: avl_vehiculo.id, avl_vehiculo.id_clase, avl_vehiculo.descripcion, avl_vehiculo.patente, avl_vehiculo.info, avl_vehiculo.numero, avl_vehiculo.conductor, avl_vehiculo.combustible, avl_vehiculo.consumo, avl_vehiculo.marca, av (...)
                          Index Cond: (avl_vehiculo.id = avl_vehiculo_equipo.id)
              ->  Index Scan using index_cliente_avl_vehiculo_id on public.cliente_avl_vehiculo  (cost=0.00..0.33 rows=1 width=8) (never executed)
                    Output: cliente_avl_vehiculo.cliente_rut, cliente_avl_vehiculo.vehiculo_id, cliente_avl_vehiculo.id_cliente, cliente_avl_vehiculo.grupo
                    Index Cond: (cliente_avl_vehiculo.vehiculo_id = avl_vehiculo.id)
        ->  Index Scan using fki_cliente_avl_equipo_imei on public.cliente_avl_equipo  (cost=0.00..7.36 rows=1 width=12) (never executed)
              Output: cliente_avl_equipo.rut_cliente, cliente_avl_equipo.imei_equipo, cliente_avl_equipo.id_cliente
              Index Cond: (cliente_avl_equipo.imei_equipo = 1234)
  ->  Index Scan using index_avl_vehiculo_clase_id on public.avl_vehiculo_clase  (cost=0.00..0.27 rows=1 width=62) (never executed)
        Output: avl_vehiculo_clase.id, avl_vehiculo_clase.descripcion, avl_vehiculo_clase.categoria, avl_vehiculo_clase.icono
        Index Cond: (avl_vehiculo_clase.id = avl_vehiculo.id_clase)
Total runtime: 1.535 ms