Hace medio año - público a PostgreSQL.
En los últimos meses hemos hecho sobre él , preparó un resumen basándonos en las recomendaciones que da... pero lo más importante, recopilamos sus comentarios y analizamos casos de uso reales.
Y ahora estamos listos para informarle sobre las nuevas funciones que puede usar.
Soporte para diferentes formatos de planes.
Plan del registro, junto con la solicitud
Directamente desde la consola, seleccionamos todo el bloque, comenzando desde la línea con Texto de consulta, con todos los espacios iniciales:
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
... y tirar todo lo copiado directamente al campo del plano, sin separar nada:
A la salida, también obtenemos una bonificación al plan desmontado. pestaña de contexto, donde se presenta en todo su esplendor nuestra petición:
JSON y YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"Incluso con comillas externas, como copias de pgAdmin, incluso sin ellas, lanzamos en el mismo campo, el resultado es hermoso:
visualización avanzada
Tiempo de Planificación / Tiempo de Ejecución
Ahora puede ver mejor a dónde se fue el tiempo extra al ejecutar la consulta:
Temporización de E/S
A veces tienes que lidiar con una situación en la que, en términos de recursos, parece que no se leyó ni escribió demasiado, pero parece que el tiempo de ejecución es incongruentemente grande por alguna razón.
Hay que decirlo aquí:Oh, probablemente, en ese momento el disco en el servidor estaba demasiado sobrecargado, ¡por eso tardó tanto en leer!"Pero de alguna manera no es muy preciso...
Pero se puede determinar de forma absolutamente fiable. El caso es que entre las opciones de configuración del servidor PG se encuentran :
Habilita las operaciones de E/S temporizadas. Esta configuración está deshabilitada de forma predeterminada, ya que requiere que el sistema operativo consulte constantemente la hora actual, lo que puede ralentizar significativamente las cosas en algunas plataformas. Puede usar la utilidad pg_test_timing para estimar la sobrecarga de tiempo en su plataforma. Las estadísticas de E/S se pueden obtener a través de la vista pg_stat_database, en la salida EXPLAIN (cuando se usa el parámetro BUFFERS) ya través de la vista pg_stat_statements.
Esta opción también se puede habilitar dentro de una sesión local:
SET track_io_timing = TRUE;Bueno, ahora lo mejor es que hemos aprendido a entender y mostrar estos datos, teniendo en cuenta todas las transformaciones del árbol de ejecución:
Aquí puede ver que de los 0.790 ms del tiempo total de ejecución, 0.718 ms tomó leer una página de datos, 0.044 ms, escribirlos, ¡y solo 0.028 ms se gastaron en todas las demás actividades útiles!
Futuro con PostgreSQL 13
Para obtener una descripción general completa de las novedades, consulte , y estamos hablando específicamente de cambios en los planes.
Colchones de planificación
La contabilidad de los recursos asignados al programador se refleja en otro parche que no está relacionado con pg_stat_statements. EXPLAIN con la opción BUFFERS informará el número de búferes utilizados durante la fase de planificación:
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
Ordenación incremental
En los casos en que sea necesario ordenar por muchas claves (k1, k2, k3...), el planificador ahora puede aprovechar el hecho de saber que los datos ya están ordenados por varias de las primeras claves (por ejemplo, k1 y k2). En este caso, no puede reordenar todos los datos nuevamente, sino dividirlos en grupos sucesivos con los mismos valores de k1 y k2, y "reordenarlos" por la clave k3.
Así, toda la clasificación se fragmenta en varias clasificaciones sucesivas de menor tamaño. Esto reduce la cantidad de memoria requerida y también le permite devolver los primeros datos antes de que se complete toda la clasificación.
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
Mejoras de UI/UX
¡Las capturas de pantalla están en todas partes!
Ahora en cada pestaña hay una oportunidad de rápidamente tomar captura de pantalla de la pestaña al portapapeles para todo el ancho y la profundidad de la pestaña - "vista" arriba a la derecha:
De hecho, la mayoría de las imágenes de esta publicación se obtuvieron de esta manera.
Recomendaciones sobre nodos
No solo hay más de ellos, sino de cada uno que puede siguiendo el enlace:
Eliminar del archivo
Algunos han pedido la capacidad de eliminar "absolutamente" incluso planes que no están publicados en el archivo - por favor, simplemente haga clic en el icono correspondiente:
Bueno, no olvidemos que tenemos donde puedes escribir tus comentarios y sugerencias.
Fuente: habr.com