Estou tentando entender melhor como o planejador de consultas funciona no postgresql.
Eu tenho esta consulta:
select id from users
where id <> 2
and gender = (select gender from users where id = 2)
order by latest_location::geometry <-> (select latest_location from users where id = 2) ASC
limit 50
Ele roda em menos de 10 ms no meu banco de dados, com cerca de 500 mil entradas na tabela de usuários.
Então, pensei que, para evitar as sub-seleções duplicadas, eu poderia reescrever a consulta como um CTE, assim:
with me as (
select * from users where id = 2
)
select u.id, u.popularity from users u, me
where u.gender = me.gender
order by u.latest_location::geometry <-> me.latest_location::geometry ASC
limit 50;
No entanto, essa consulta reescrita é executada em cerca de 1 segundo! Por que isso acontece? Vejo no explica que ele não usa o índice de geometria, mas algo pode ser feito para isso? Obrigado!
Outra maneira de escrever a consulta é:
select u.id, u.popularity from users u, (select gender, latest_location from users where id = 2) as me
where u.gender = me.gender
order by u.latest_location::geometry <-> me.latest_location::geometry ASC
limit 50;
No entanto, isso também será tão lento quanto o CTE.
Se, por outro lado, extraio os parâmetros me e os insiro estaticamente, a consulta é rápida novamente:
select u.id, u.popularity from users u
where u.gender = 'male'
order by u.latest_location::geometry <-> '0101000000A49DE61DA71C5A403D0AD7A370F54340'::geometry ASC
limit 50;
Explicar a primeira consulta (rápida)
Limit (cost=5.69..20.11 rows=50 width=36) (actual time=0.512..8.114 rows=50 loops=1)
InitPlan 1 (returns $0)
-> Index Scan using users_pkey on users users_1 (cost=0.42..2.64 rows=1 width=32) (actual time=0.032..0.033 rows=1 loops=1)
Index Cond: (id = 2)
InitPlan 2 (returns $1)
-> Index Scan using users_pkey on users users_2 (cost=0.42..2.64 rows=1 width=4) (actual time=0.009..0.010 rows=1 loops=1)
Index Cond: (id = 2)
-> Index Scan using users_latest_location_gix on users (cost=0.41..70796.51 rows=245470 width=36) (actual time=0.509..8.100 rows=50 loops=1)
Order By: (latest_location <-> $0)
Filter: (gender = $1)
Rows Removed by Filter: 20
Total runtime: 8.211 ms
(12 rows)
Explique a segunda consulta (lenta)
Limit (cost=62419.82..62419.95 rows=50 width=76) (actual time=1024.963..1024.970 rows=50 loops=1)
CTE me
-> Index Scan using users_pkey on users (cost=0.42..2.64 rows=1 width=221) (actual time=0.037..0.038 rows=1 loops=1)
Index Cond: (id = 2)
-> Sort (cost=62417.18..63030.86 rows=245470 width=76) (actual time=1024.959..1024.963 rows=50 loops=1)
Sort Key: ((u.latest_location <-> me.latest_location))
Sort Method: top-N heapsort Memory: 28kB
-> Hash Join (cost=0.03..54262.85 rows=245470 width=76) (actual time=0.122..938.131 rows=288646 loops=1)
Hash Cond: (u.gender = me.gender)
-> Seq Scan on users u (cost=0.00..49353.41 rows=490941 width=48) (actual time=0.021..465.025 rows=490994 loops=1)
-> Hash (cost=0.02..0.02 rows=1 width=36) (actual time=0.054..0.054 rows=1 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> CTE Scan on me (cost=0.00..0.02 rows=1 width=36) (actual time=0.047..0.049 rows=1 loops=1)
Total runtime: 1025.096 ms
FROM
vez do termo CTE para obter melhores resultados.(select id, latest_location from users where id = 2)
como o cte? Talvez seja o * que está causando esse problemaRespostas:
Tente o seguinte:
Quando olho para o plano rápido, eis o que salta para mim (em negrito):
Na versão lenta, o planejador de consultas está avaliando o operador de igualdade
gender
e o operador de geometrialatest_location
no contexto de uma junção , onde o valor deme
pode variar com cada linha (mesmo que tenha estimado corretamente apenas 1 linha). Na versão rápida, os valores degender
elatest_location
são tratados como escalares porque são emitidos por subconsultas em linha, o que indica ao planejador de consultas que ele possui apenas um valor para cada um. Esse é o mesmo motivo pelo qual você obtém o plano rápido ao colar os valores literais.fonte
me
dafrom
cláusula agora.