Hola, esta parte revisa si lo puedes trabajar, los filtros son después de una
lectura de disco o indices para reducir la lectura puedes crear un indice con
los filtros.
Index Cond: ((fulldate >= '2025-01-31 09:30:00'::timestamp without time zone)
AND (fulldate < '2025-02-04 09:30:00'::timestamp
Guillermo E. Villanueva 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
¿y qué dice esto?
select attname, cardinality(histogram_bounds), cardinality(most_common_freqs)
Gracias.
Lo sigue planificando mal con ese random_page_cost
El mié, 5 feb 2025 a las 11:13, Jairo Graterón ()
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.
>
> Sa
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 índic
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 ()
escribió:
> Guillermo E. Villanueva escribió:
> > Jaja si engaño a pg y cambio la condición
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
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
por
https://explain.depesz.com/s/R3Fh
Si lo ejecuto solo hasta el filtro de companies.id devuelve el resultado en
menos de 1 segundo
Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las
PK porque priorizar un indice de la misma tabla donde las columnas no son
PK?
El mar, 4 feb 2
Es de tipo integer
probé con "companies"."id" = ANY (ARRAY[1381059542::integer, 1380939758::
integer, 1380939757::integer, 1380939753::integer])
pero lo sigue poniendo como filtro dentro de la búsqueda de otro indice que
no es PK
El mar, 4 feb 2025 a las 19:49, Jairo Graterón ()
escribió:
> Salu
