2009-10-08 26 views
19

He encontrado una serie de recursos que hablan sobre el ajuste del servidor de la base de datos, pero no he encontrado mucho sobre la sintonización de las consultas individuales.¿Guías para el ajuste de consultas PostgreSQL?

Por ejemplo, en Oracle, podría intentar agregar sugerencias para ignorar índices o utilizar sort-merge vs. joins correlacionados, pero no puedo encontrar mucho en tuning Postgres que no sea using explicit joins y recomendaciones cuando bulk loading tables.

¿Existe alguna de estas guías, por lo que puedo centrarme en ajustar las consultas más ejecutadas y/o de bajo rendimiento, con suerte sin afectar negativamente a las consultas que actualmente se desempeñan bien?

Incluso me gustaría encontrar algo que comparase el tipo de consultas realizadas en relación con otras bases de datos, así que tenía una mejor idea de qué tipo de cosas evitar.

actualización:

Yo he mencionado, tomé todas las clases de DBA Oracle junto con sus clases de modelado de datos y ajuste de SQL en los días 8i ... así que sé de 'explicar' , pero eso es más para decirte qué está pasando con la consulta, no necesariamente cómo hacerlo mejor. (por ejemplo, son 'mientras var = 1 o var = 2' y 'mientras que var in (1,2)' considera lo mismo al generar un plan de ejecución? ¿Qué pasa si lo hago con 10 permutaciones? ¿Cuándo son multi-columna índices usados? ¿Hay formas de conseguir que el planificador optimice para el inicio más rápido frente al final más rápido? ¿Qué tipo de 'errores' puedo encontrar al pasar de mySQL, Oracle o algún otro RDBMS?)

Podría escribir cualquier consultas complejas docenas, sino cientos de maneras, y espero no tener que probarlas todas y encontrar cuál funciona mejor a través de prueba y error. Ya he encontrado que 'SELECT count (*)' no usará un índice, pero 'SELECT count (primary_key)' será ... tal vez un tipo de documento 'PostgreSQL para usuarios de SQL con experiencia' que explicará los tipos de consultas a evitar, y la mejor forma de volver a escribirlos, o cómo hacer para que el planificador los maneje mejor.

actualización 2:

encontré una Comparison of different SQL Implementations que cubre PostgreSQL, DB2, MS-SQL, MySQL, Oracle e Informix, y explica si, cómo y propensas a error sobre las cosas que puede tratar de hacer, y su sección de referencias vinculada a Oracle/SQL Server/DB2/Mckoi /MySQL Database Equivalents (que es lo que sugiere su título) y al wikibook SQL Dialects Reference que cubre lo que la gente contribuya (incluye algunos DB2, SQLite, MySQL, PostgreSQL, Firebird, Vituoso, Oracle, MS-SQL, Ingres y Linter) .

+0

No es exactamente la optimización de consultas, pero para aquellos que provienen de mysql, esto podría ser útil: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL – Joe

+0

Y para personas que vienen de Oracle: http: //www.cs.cmu .edu/~ pmerson/docs/OracleToPostgres.pdf; y en general 'atrapados' para postgres: http://sql-info.de/postgresql/postgres-gotchas.html – Joe

+0

Esto podría ser útil para su afinación de postgres: http://tekadempiere.blogspot.ae/2014/09/ tuning-postgresql-for-better-performance.html – Sajeev

Respuesta

5

http://www.postgresql.org/docs/current/static/indexes-examine.html

Puede dar pistas: SET enable_indexscan TO false; haría PostgreSQL tratar de no utilizar índices

+0

Ah ... No me di cuenta de que las configuraciones en la sección 'Planificación de consultas' de los documentos (http://www.postgresql.org/docs/current/static/runtime-config-query.html) podrían establecerse por sección. – Joe

3

mejor que he visto son de aquí: , pero la última PDF allí es a partir de 2008, por lo que hay puede ser algo más reciente. Me interesa escuchar las respuestas de otros usuarios.

Además, elaboración de la cerveza de algo en los paquetes de contrib: http://www.sai.msu.su/~megera/wiki/plantuner

4

La herramienta pgadmin3 incluye una herramienta gráfica explicación para romper cómo se maneja una consulta. También es especialmente útil para mostrar dónde se realizan los escaneos de tabla.

5

Para abordar su punto, desafortunadamente la única forma de ajustar una consulta en Postgres es ajustar la base de datos subyacente.En Oracle, puede establecer todas esas opciones en una consulta por consulta, superar el plan de optimizadores en el proceso, pero en Postgres, está casi a merced del optimizador, para bien y para mal.

11

En cuanto a las consultas de bajo rendimiento, explique analice y léalo.

Puede poner explique explique la salida en el sitio como explain.depesz.com - le ayudará a encontrar los elementos que realmente toman más tiempo.

6

Hay una buena herramienta en línea que toma la salida de EXPLAIN ANALYZE, y gráficamente muestra que las partes críticas (por ejemplo, estimaciones erróneas, puntos calientes, etc.)

http://explain.depesz.com/help

Por cierto, creo que las consultas publicadas se hacen públicos , y el enlace "explica anterior" ha sido golpeado por spambots.

Cuestiones relacionadas