> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8a08bda2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Query insights de Postgres
> Telemetría por sentencia para Managed Postgres: todos los patrones de consulta que ejecuta tu base de datos, ordenados por impacto, con los contadores de diagnóstico que explican por qué cada uno es lento
export const Image = ({img, alt, size}) => {
return
;
};
export const galaxyOnClick = eventName => () => {
try {
if (typeof window !== "undefined" && window.galaxy && eventName) {
window.galaxy.track(eventName, {
interaction: "click"
});
}
} catch (e) {}
};
export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
if (link) {
return
Beta
;
}
return ;
};
Query Insights captura la telemetría por sentencia de tu instancia de
[Managed Postgres](/es/products/managed-postgres/overview) y clasifica cada patrón de consulta
según su impacto, para que puedas pasar de "el p99 está aumentando" a "este patrón
se está volcando a disco" sin salir de la consola de Cloud.
Los datos provienen de [`pg_stat_ch`](https://github.com/clickhouse/pg_stat_ch),
la extensión de Postgres de código abierto que transmite contadores por sentencia a
ClickHouse Cloud. La telemetría se normaliza dentro de Postgres antes de salir
de la base de datos: se eliminan los literales y se sustituyen por marcadores de posición, de modo que los
valores exactos que consultas nunca entran en el flujo de telemetría.
## Abra Query insights
Abra su instancia de Managed Postgres en la Cloud Console y haga clic en
**Query insights** en la barra lateral izquierda. La página se divide en cuatro
secciones, en el orden en que realmente las usaría:
* Un **Overview** que permite ver el estado general de la base de datos en una sola pantalla.
* Una tabla de **Slow patterns** que clasifica cada patrón de consulta que su base de datos
ha ejecutado, ordenada según lo que sospeche.
* Un panel de **Recent queries** que muestra las ejecuciones individuales en orden cronológico inverso.
* Un **panel lateral de detalles** que agrega todos los contadores de un mismo patrón.
Use el selector de **Time period** en la parte superior para alternar entre los últimos 15
minutos, la última hora, el último día, la última semana o el último mes. El tamaño del bucket de agregación se ajusta
automáticamente: buckets de 1 minuto para los últimos 15 minutos o la última hora,
de 5 minutos para el último día y de 1 hora para la última semana o el último mes, para que los
gráficos sigan respondiendo con fluidez.
## Overview
El Overview es una cuadrícula de 3×2 con seis paneles:
| Panel | Qué muestra |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Consultas/s** | Volumen de consultas normalizado como una tasa en la ventana seleccionada. |
| **Latencia de consultas** | Media, p50, p95 y p99 en un solo gráfico, para que puedas ver cuándo la cola se aleja de la mediana. |
| **Desglose de operaciones** | Un gráfico de anillo con la proporción real de operaciones `SELECT`, `INSERT`, `UPDATE` y otras que componen la carga de trabajo. |
| **Filas devueltas / afectadas** | Total de filas que la carga de trabajo movió durante la ventana. |
| **Tasa de aciertos del búfer** | Un gráfico de anillo que compara los bloques compartidos encontrados en caché con los bloques compartidos leídos, con el tiempo total de CPU en la leyenda. |
| **Errores** | Recuento total de errores, desglosado a lo largo del tiempo. |
Una sola pantalla te indica si la base de datos está en buen estado. Una instancia en buen estado
tiene un patrón reconocible: una tasa de aciertos del búfer por encima del 90 %, un volumen de consultas
que evoluciona con el tráfico de la aplicación, una tasa de errores estable o nula, y latencias
percentilares que se mantienen muy próximas entre sí.
## Slow patterns
Cuando el resumen apunta a problemas, la tabla de patrones es donde
empieza la investigación. Una fila por cada patrón de consulta normalizado, con los
literales eliminados para que las ejecuciones de la misma sentencia queden agrupadas en
la misma fila.
### Ordena por lo que sospeches
La tabla se ordena de forma predeterminada por **Tiempo de ejecución total** en orden descendente. Cuando la ordenas de esta
forma, el primer patrón suele ser la respuesta a "¿qué es lo que más me
cuesta?". Puede que no sea el patrón más lento por sí solo. Una consulta que se ejecuta
ocho millones de veces al día en doce milisegundos puede importar más que
una que se ejecutó una sola vez en tres segundos.
Cada ordenación te da una perspectiva distinta:
* **Tiempo de ejecución total** — donde la base de datos empleó más tiempo de reloj.
* **Tiempo de CPU** — patrones intensivos en cómputo.
* **Llamadas** — patrones de alta frecuencia.
* **Errores** — fallos repetidos.
* **Latencia prom. / P50 / P95 / P99 / máx.** — casos atípicos, por percentil.
* **Filas devueltas**, **Bloques leídos**, **Bloques en caché**, **Bytes de WAL** —
patrones que movieron la mayor cantidad de datos a través del motor, la caché o
el registro de escritura anticipada.
Haz clic en el botón **Columnas** para mostrar u ocultar columnas adicionales.
La tabla de patrones muestra 19 columnas en total, incluido el desglose por percentiles,
la proporción de aciertos de caché y el tiempo de CPU por patrón.
### Limita la tabla
Filtra la tabla según la parte de tu carga de trabajo que estés
investigando:
* **Base de datos**
* **Usuario**
* **Operación** (`SELECT`, `INSERT`, `UPDATE`, `DELETE`, …)
* **Aplicación** — el `application_name` de la cadena de conexión
"Muéstrame solo lo que hace el servicio de pedidos en la base de datos `sales`"
se convierte en dos menús desplegables. Los valores de filtro se rellenan automáticamente a partir de lo que tu
instancia ha ejecutado realmente.
## Recent queries
Debajo de la tabla de patrones, el panel de **Recent queries** muestra las
ejecuciones individuales en orden cronológico inverso: una fila por cada
instrucción ejecutada, no una fila por patrón. Úsalo cuando quieras ver el flujo de eventos
sin procesar en lugar de un agregado; por ejemplo, para comprobar puntualmente que una corrección
se aplicó o para encontrar el momento exacto en que se produjo un error.
Las columnas predeterminadas son Time, Operation, Query, Duration, Rows,
Database, User y Blks read. Abre el selector de **columnas** para ver
Application, Blks hit, CPU user, CPU sys y PID. La tabla admite
los mismos filtros de Database, User, Operation y Application que la
tabla de patrones, y se puede ordenar por Time, Duration, Rows, Blks read y
CPU time.
Haz clic en cualquier fila para abrir el mismo panel lateral de detalles que en la tabla de patrones,
acotado al patrón de esa única ejecución.
## Panel lateral de detalles
Haz clic en cualquier fila de la tabla de patrones o consultas recientes y el panel lateral de **detalles de la consulta** se abre a la derecha. El panel lateral toma cada ejecución
de ese patrón dentro del intervalo de tiempo seleccionado y agrega los
contadores que explican por qué es lenta.
El panel lateral es un único panel desplazable con cinco secciones:
* **Patrón de consulta** — el SQL normalizado con los literales reemplazados por `$1`,
`$2`, … y un botón para copiar al portapapeles.
* **Uso agregado de recursos** — una cuadrícula de 13 tarjetas de estadísticas que cubren el total de
llamadas, latencia prom./P95/P99/máx., tiempo total de ejecución, filas devueltas, tasa de aciertos en caché,
bloques leídos, bloques encontrados en caché, tiempo de CPU, bytes de WAL y errores.
* **Contexto de la consulta** — la base de datos, el usuario, la operación y la aplicación
de la que procede este patrón.
* **Ejecuciones destacadas** — errores, ejecuciones inusualmente lentas y
ejecuciones con resultados grandes, mostradas antes de la lista completa de ejecuciones recientes.
* **Ejecuciones recientes** — las ejecuciones individuales del mismo patrón,
con contadores por ejecución.
### Contadores por ejecución
Al expandir una ejecución reciente, verás los contadores que muestran con precisión en qué
se fue el tiempo:
* **Bloques compartidos** — las lecturas y los aciertos se muestran siempre; las escrituras y los bloques sucios
se muestran cuando no son cero.
* **Operaciones con bloques locales y temporales** — si las operaciones con bloques temporales son distintas de cero, significa que una ordenación o una operación hash
se volcó a disco.
* **Tiempo de lectura / escritura** — tiempo de E/S, separado del tiempo de CPU.
* **Tiempo de CPU** — usuario y sistema, por separado.
* **Workers en paralelo** — planificados frente a los realmente iniciados.
* **JIT** — tiempo total de compilación JIT y cantidad de funciones.
* **WAL** — bytes y número de registros.
Todo lo necesario para diagnosticar un patrón lento está en un solo lugar, en una sola
pantalla.
## API de Query insights
La misma telemetría está disponible mediante programación a través de
[ClickHouse Cloud OpenAPI](/es/products/managed-postgres/openapi#query-insights).
La tabla [Slow patterns](#slow-patterns) se corresponde con el
endpoint
[list slow query patterns](/es/api-reference/organization/get-list-of-available-organizations#tag/Postgres/operation/slowQueryPatternsGetList),
y el [panel lateral de detalles](#detail) se corresponde con el
endpoint
[get slow query pattern](/es/api-reference/organization/get-list-of-available-organizations#tag/Postgres/operation/slowQueryPatternGet),
que devuelve las métricas agregadas de un patrón junto con sus
ejecuciones recientes.
## Cómo funciona
### Normalizado en Postgres, antes de pasar por la red
`pg_stat_ch` se engancha a la fase de análisis sintáctico, sustituye cada literal por un
marcador de posición (`$1`, `$2`, …) y almacena en caché el patrón resultante en una
LRU por backend indexada por `queryid`. Cuando el ejecutor termina la
sentencia, ese patrón almacenado en caché es lo que se adjunta al evento. La
sentencia exacta con valores nunca sale de la base de datos.
### Sin interferir con la base de datos
El productor añade aproximadamente un 3 % de sobrecarga por sentencia. La ruta de encolado
usa un try-lock no bloqueante sobre un búfer circular en memoria compartida. Bajo
carga, la extensión descarta eventos y los contabiliza con un contador, en lugar de
aplicar contrapresión a Postgres.
### Eventos sin procesar, no agregados
`pg_stat_ch` emite un evento sin procesar por cada sentencia ejecutada (de nivel superior y
anidada), según el muestreo aplicado. Cada percentil, ranking y desglose
en la UI es una consulta de ClickHouse sobre el mismo flujo de eventos.
### El mismo motor que usan nuestros clientes
El backend de Insights es [ClickHouse Cloud](/es/products/cloud/getting-started/intro).
La telemetría por consulta de una instancia de Postgres con mucha actividad genera millones de filas
al día; la compresión columnar hace que sea económico conservar durante meses los detalles de cada ejecución,
y las agregaciones en menos de un segundo sobre miles de millones de filas mantienen la
UI interactiva mientras exploras datos de una semana o de un mes.
### Código abierto
`pg_stat_ch` se distribuye bajo Apache 2.0. Ejecútalo con cualquier Postgres y envíalo a cualquier
ClickHouse. El código fuente y los issues están en
[github.com/clickhouse/pg\_stat\_ch](https://github.com/clickhouse/pg_stat_ch).
## Páginas relacionadas
* [Panel de monitoreo](/es/products/managed-postgres/monitoring/dashboard) — gráficos integrados de recursos y actividad
* [Endpoint de Prometheus](/es/products/managed-postgres/monitoring/prometheus) — recopila métricas a nivel de host en tu propia pila de observabilidad
* [Managed Postgres OpenAPI](/es/products/managed-postgres/openapi#query-insights) — consulta patrones lentos y ejecuciones recientes de forma programática
* [Extensiones](/es/products/managed-postgres/extensions) — las extensiones disponibles en las instancias de Managed Postgres
* [`pg_stat_ch` en GitHub](https://github.com/clickhouse/pg_stat_ch) — la extensión de código abierto que potencia Query Insights