Gracias. Lo sigue planificando mal con ese random_page_cost El mié, 5 feb 2025 a las 11:13, Jairo Graterón (<jgrate...@gmail.com>) escribió:
> Buen día > > prueba modificando ésta variable (al ejecutar en psql sólo lo modifica la > sesión actual) > > set random_page_cost=1.0; > > y luego el explain original. > > Saludos. > > > El mié, 5 feb 2025 a las 8:35, Guillermo E. Villanueva (< > guillermo...@gmail.com>) escribió: > >> Hola Alvaro cómo estas? >> Los índices de los que hablo tienen unos 27GB cada uno >> La tabla tiene unos 1.4TB >> >> effective_cache_size = 48GB >> shared_buffers = 24GB >> >> El mié, 5 feb 2025 a las 9:13, Álvaro Herrera (<alvhe...@alvh.no-ip.org>) >> escribió: >> >>> Guillermo E. Villanueva escribió: >>> > Jaja si engaño a pg y cambio la condición >>> > and companies.fulldate::text >= '2025-01-31 09:30' and >>> companies.fulldate:: >>> > text < '2025-02-04 09:30' >>> > >>> > ya no usa el índice secundario, usa el índice de la PK y resuelve la >>> query >>> > en menos de un segundo , lo tengo resuelto así pero me quedo con la >>> duda de >>> > porque el planificador lo hace mal de la otra manera (para mi) >>> >>> Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en >>> effective_cache_size y shared_buffers? >>> >>> -- >>> Álvaro Herrera PostgreSQL Developer — >>> https://www.EnterpriseDB.com/ >>> >>
