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

255
Vistas
Análisis de parámetros/búsqueda de enlaces en PostgresSQL

La combinación Preparar y Ejecutar en PostgreSQL permite el uso de parámetros enlazados. Sin embargo, Prepare no produce un plan optimizado para un conjunto de enlaces de parámetros que se puede reutilizar con un conjunto diferente de enlaces de parámetros. ¿Alguien tiene sugerencias sobre cómo implementar dicha funcionalidad? Con esto, el plan se optimizaría para el conjunto dado de enlaces de parámetros, pero podría reutilizarse para otro conjunto. Es posible que el plan no sea eficiente para el conjunto posterior, pero si el costo del plan se volvió a calcular utilizando los nuevos enlaces de parámetros, es posible que sea eficiente.

La lectura y el uso de valores de vinculación de parámetros para la estimación de cardinalidad se denomina "olfateo de parámetros" en SQL Server y "búsqueda de vinculación" en Oracle. Básicamente, ¿alguien ha hecho algo similar en PostgreSQL?

gracias campbell

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

0

PostgreSQL usa una heurística para decidir si se debe hacer "mirar a escondidas". Echa un vistazo las primeras 5 veces (creo que lo es) que se ejecuta una declaración preparada, y si ninguno de ellos conduce a planes mejores (que se espera que sean mejores) que el plan genérico, deja de verificar en el futuro .

A partir de v12, puede cambiar esta heurística configurando plan_cache_mode.

Tenga en cuenta que algunos controladores implementan sus propias heurísticas: el hecho de que llame al método de preparación del controlador no significa que realmente transmita esto al servidor como PREPARE. En su lugar, podría ocultar el texto de la declaración, esperar hasta que se ejecute y luego citar/escapar sus parámetros y agruparlos con su declaración pseudo-preparada previamente y enviarlos al servidor en un solo paquete. Es decir, podrían tratar la separación preparar/ejecutar simplemente como una forma de evitar las inyecciones de SQL, no como una forma de aumentar el rendimiento.

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