views:

802

answers:

6

I've found a number of resources that talk about tuning the database server, but I haven't found much on the tuning of the individual queries.

For instance, in Oracle, I might try adding hints to ignore indexes or to use sort-merge vs. correlated joins, but I can't find much on tuning Postgres other than using explicit joins and recommendations when bulk loading tables.

Do any such guides exist so I can focus on tuning the most run and/or underperforming queries, hopefully without adversely affecting the currently well-performing queries?

I'd even be happy to find something that compared how certain types of queries performed relative to other databases, so I had a better clue of what sort of things to avoid.

update:

I should've mentioned, I took all of the Oracle DBA classes along with their data modeling and SQL tuning classes back in the 8i days ... so I know about 'EXPLAIN', but that's more to tell you what's going wrong with the query, not necessarily how to make it better. (eg, are 'while var=1 or var=2' and 'while var in (1,2)' considered the same when generating an execution plan? What if I'm doing it with 10 permutations? When are multi-column indexes used? Are there ways to get the planner to optimize for fastest start vs. fastest finish? What sort of 'gotchas' might I run into when moving from mySQL, Oracle or some other RDBMS?)

I could write any complex query dozens if not hundreds of ways, and I'm hoping to not have to try them all and find which one works best through trial and error. I've already found that 'SELECT count(*)' won't use an index, but 'SELECT count(primary_key)' will ... maybe a 'PostgreSQL for experienced SQL users' sort of document that explained sorts of queries to avoid, and how best to re-write them, or how to get the planner to handle them better.

update 2:

I found a Comparison of different SQL Implementations which covers PostgreSQL, DB2, MS-SQL, mySQL, Oracle and Informix, and explains if, how, and gotchas on things you might try to do, and his references section linked to Oracle / SQL Server / DB2 / Mckoi /MySQL Database Equivalents (which is what its title suggests) and to the wikibook SQL Dialects Reference which covers whatever people contribute (includes some DB2, SQLite, mySQL, PostgreSQL, Firebird, Vituoso, Oracle, MS-SQL, Ingres, and Linter).

+2  A: 

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

You can give hints: SET enable_indexscan TO false; would make PostgreSQL try to not use indexes

synecdoche
Ah ... I didn't realize the settings in the 'Query Planning' section of the docs ( http://www.postgresql.org/docs/current/static/runtime-config-query.html ) could be set per session.
Joe
+1  A: 

Best I've seen are in here: http://wiki.postgresql.org/wiki/Using%5FEXPLAIN, but the latest PDF in there is from 2008, so there may be something more recent. I'm interested to hear other user's answers.

Also, something's brewing in the contrib packages: http://www.sai.msu.su/~megera/wiki/plantuner

hgimenez
+1  A: 

The PGAdmin3 tool includes a graphical explanation tool for breaking down how a query is handled. It also is especially helpful for showing where table scans occur.

monksy
+1  A: 

To address your point, unfortunately the only way to tune a query in Postgres is pretty much to tune the database underlying it. In oracle, you can set all of those options on a query by query basis, trump the optimizers plan in the process, but in Postgres, you're pretty much at the mercy of the optimizer, for good and ill.

Will Hartung
+4  A: 

As for badly performing queries - do explain analyze and read it.

You can put explain analyze output on site like explain.depesz.com - it will help you find the elements that really take the most time.

depesz
+1  A: 

There is a nice online tool that takes the output of EXPLAIN ANALYZE, and graphically shows you critical parts (e.g. wrong estimates, hot spots, etc)

http://explain.depesz.com/help

Btw, I think posted queries become public, and the "previous explains" link has been hit by spambots.

Marco Mariani