Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

224
Vistas
PostgreSQL aspirando una mesa grande

Tengo Postgres 9.4.7 y tengo una tabla grande de ~100 millones de filas y 20 columnas. Las consultas de la tabla son selecciones de 1.5k, inserciones de 150 y actualizaciones de 300 por minuto, aunque sin eliminaciones. Aquí está mi configuración de autovacuum:

autovacuum_analyze_scale_factor 0
autovacuum_analyze_threshold 5000
autovacuum_vacuum_scale_factor 0
autovacuum_vacuum_threshold 5000
autovacuum_max_workers 6
autovacuum_naptime 5s

En mi caso, la base de datos casi siempre está en el estado constante de aspirado. Cuando finaliza una sesión de aspirado, comienza otra.

Entonces, la pregunta principal: ¿Existe una forma común de aspirar mesas grandes?

Aquí hay algunas otras preguntas.

El vacío estándar no escanea toda la tabla y "analiza" solo escanea 30k filas. Entonces, bajo la misma carga, debería tener un tiempo de ejecución constante, ¿es cierto? ¿Realmente necesito analizar la tabla? ¿Puede el 'analizar' frecuente hacer cambios útiles en los planes de consulta para una tabla grande?

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Aspirar

VACUUM recupera el almacenamiento ocupado por tuplas muertas.

Por lo tanto, solo cambia las páginas afectadas, pero escaneará toda la tabla.

Eso se refiere a lo que probablemente llamas "vacío estándar". Ahora si tienes 9.6, entonces

VACUUM saltará páginas según el mapa de visibilidad

analizar

la cantidad de datos que analiza ANALYZEdepende del tamaño de la tabla y del conjunto de objetivos de default_statistics_target por instancia o por tabla; no son 30 000 per se:

Para tablas grandes, ANALYZE toma una muestra aleatoria del contenido de la tabla, en lugar de examinar cada fila... cambia ligeramente cada vez que se ejecuta ANALYZE, incluso si el contenido real de la tabla no cambió. Esto podría resultar en pequeños cambios en los costos estimados del planificador que muestra EXPLAIN.

Entonces, si desea obtener resultados más estables para EXPLAIN, ejecute algo como

 alter table ... alter COLUMN ... set STATISTICS 200;

o aumente default_statistics_target, de lo contrario, con demasiada frecuencia, el análisis tiene más posibilidades de cambiar el plan.

Una cosa más: tienes un umbral de 5K. En una tabla con filas de 100000K es 0.002%, ¿verdad? entonces la escala es 0.00002? mientras que por defecto uno en 0.2 o 0.1... Me hace pensar que tal vez tienes un umbral demasiado bajo. De hecho, se recomienda hacer funcionar la aspiradora con más frecuencia, pero aquí parece demasiado a menudo. Como mil veces más a menudo de lo que sería por defecto...

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda