Muchas gracias Alvaro, tremendo crack ud. Luego de ejecutar (en un ambiente de testing)
ALTER TABLE companies ALTER id SET STATISTICS 10000; ALTER TABLE companies ALTER fulldate SET STATISTICS 10000; ANALYZE companies; El explain de la query en cuestión cambió totalmente Ahora si utiliza primero el índice de la clave primaria y luego recien filtra por fechas Si me puedes remitir a algun material para leer al respecto y entender porque pasaba esto y por que se solucionó te lo agradeceré! Aunque no necesité la otra solución que comentabas, si me gustaría saberla, intenté algunas cosas con subqueries pero no mejoraba, lo único que mejoró fue el casteo and companies.fulldate*::text* >= '2025-01-31 09:30' and companies.fulldate *::text* < '2025-02-04 09:30' De esa manera (parche) evitaba que use el otro índice y se iba por el de la PK Muchas gracias de nuevo El jue, 6 feb 2025 a las 8:56, Álvaro Herrera (<alvhe...@alvh.no-ip.org>) escribió: > Guillermo E. Villanueva escribió: > > Alvaro te copio el resultado acá: > > id 101 > > subclient_id 101 100 > > hidden_by_contact 101 6 > > fulldate 101 > > OK, quizás te sirva tomar más estadísticas para id y fulldate. > ALTER TABLE companies ALTER id SET STATISTICS 10000; > ALTER TABLE companies ALTER fulldate SET STATISTICS 10000; > ANALYZE companies; > > Con eso, los datos estadísticos sobre esas dos columnas podrían ser más > precisos y potencialmente corregir el problema. OJO: el valor 10000 > puede ser excesivamente alto y causar que la optimización de consultas > tome más tiempo. Mídelo y experimenta bajando ese número desde 10000 a > algo entre eso y 100 (el que tienes ahora). Opcionalmente, considerar > las otras columnas que tu consulta tiene en el WHERE. > > > Si eso no resulta, podrías probar con > CREATE STATISTICS ON id, fulldate FROM companies; > ANALYZE; > > Eso captura estadísticas cruzadas entre esas dos columnas, lo cual > podría informar mejor al optimizador respecto del uso de ambas en el > WHERE. Al igual que lo de arriba, puede servir opcionalmente agregar > las otras columnas que tienes en el WHERE. > > > Si nada de lo anterior resulta, la siguiente opción es forzar el uso del > indexscan metiendo el scan de esa tabla en un subselect. Cuando nos > cuentes del resultado de arriba puedo explicar cómo se hace esto. > > Saludos > > -- > Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ > "Sallah, I said NO camels! That's FIVE camels; can't you count?" > (Indiana Jones) >
