Tengo la siguiente consulta, bastante simple, que estoy ejecutando usando JDBC que está tardando demasiado en ejecutarse. La base de datos es un servidor AWS RDS. La tabla rt2 tiene alrededor de 600 000 entradas y la tabla CM2 alrededor de 300 000. La consulta devuelve 11230 filas.
SELECT cm2.target from sysmgmt.sys_root rt2 join cmgmt.member cm2 on cm2.cmid = rt2.cmid and cm2.version=rt2.work_version_id where rt2.tid=1001 and rt2.proj='d791194b-f2b7-42a7-aba7-f879e052e59d'::uuid and rt2.deleted = false and cm2.tid=1001 and cm2.proj = 'd791194b-f2b7-42a7-aba7-f879e052e59d'::uuid;Cuando ejecuto esta consulta con la llamada JDBC, ¡tarda 40 segundos! Sin embargo, si ejecuto exactamente esta misma consulta en una línea de comando PSQL en la misma máquina, es casi instantáneo.
Ejecutar EXPLAIN ANALYZE muestra el siguiente plan.
Nested Loop (cost=0.85..7.77 rows=1 width=176) (actual time=0.030..36.067 rows=11230 loops=1) -> Index Scan using m_cell_tid_proj_version_idx on member cm2 (cost=0.42..3.32 rows=1 width=197) (actual time=0.020..2.988 rows=11230 loops=1) Index Cond: ((tid = '1001'::numeric) AND (proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid)) -> Index Scan using sys_root_cmid_workversion_idx on sys_root rt2 (cost=0.42..4.45 rows=1 width=21) (actual time=0.002..0.002 rows=1 loops=11230) Index Cond: ((cmid = cm2.cmid) AND (work_version_id = cm2.version)) Filter: ((NOT deleted) AND (tid = '1001'::numeric) AND (proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid)) Planning Time: 0.374 ms Execution Time: 36.499 msAlgunas cosas que he intentado para acelerarlo.
Ninguno de estos parece tener ningún efecto. El código Java es bastante sencillo, ejecuta la consulta y luego repite los resultados. El tiempo se toma justo antes de ejecutar Consulta y justo después.
Took :[40644.067138] Comment:found 11230 SQL Query:[SELECT cm2.target from sysmgmt.sys_root rt2 join mgmt.member cm2 on cm2.cmid = rt2.cmid and cm2.version=rt2.work_version_id where rt2.tid=1001 and rt2.proj='ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid and cm2.tid=1001 and cm2.proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid and rt2.deleted = false]Hay alrededor de 5 a 10 otras consultas que se ejecutan en la misma transacción, ¿es posible que las otras consultas causen un problema aguas abajo cuando llega a esta consulta?
Si alguien tiene alguna idea de cuál puede ser el problema, le agradecería alguna información.
Resulta que el plan Explicar Analizar era diferente cuando se ejecutaba en el contexto de la actividad. Subir los parámetros de auto_explain y hacer que se registre en los archivos de registro de postgres mostró que el plan era diferente que cuando lo ejecuté como una solicitud independiente. La pregunta entonces se convirtió en "¿cómo hacer que haga lo correcto?". La respuesta a eso fue subir default_statistics_target de 100 a 200 y ejecutar ANALYZE en la base de datos. También reorganicé el orden de las tablas de unión. Al hacer ambas cosas, el problema ha desaparecido (con suerte, para siempre). Este wiki https://wiki.postgresql.org/wiki/Performance_Optimization también demostró ser un gran recurso.