Question

I have an application written on Play Framework 1.2.4 with Hibernate(default C3P0 connection pooling) and PostgreSQL database (9.1).

Recently I turned on slow queries logging ( >= 100 ms) in postgresql.conf and found some issues.

But when I tried to analyze and optimize one particular query, I found that it is blazing fast in psql (0.5 – 1 ms) in comparison to 200-250 ms in the log. The same thing happened with the other queries.

The application and database server is running on the same machine and communicating using localhost interface.

JDBC driver – postgresql-9.0-801.jdbc4

I wonder what could be wrong, because query duration in the log is calculated considering only database processing time excluding external things like network turnarounds etc.

Answer 1

Possibility 1: If the slow queries occur occasionally or in bursts, it could be checkpoint activity. Enable checkpoint logging (log_checkpoints = on), make sure the log level (log_min_messages) is ‘info’ or lower, and see what turns up. Checkpoints that’re taking a long time or happening too often suggest you probably need some checkpoint/WAL and bgwriter tuning. This isn’t likely to be the cause if the same statements are always slow and others always perform well.

Possibility 2: Your query plans are different because you’re running them directly in psql while Hibernate, via PgJDBC, will at least sometimes be doing a PREPARE and EXECUTE (at the protocol level so you won’t see actual statements). For this, compare query performance with PREPARE test_query(...) AS SELECT ... then EXPLAIN ANALYZE EXECUTE test_query(...). The parameters in the PREPARE are type names for the positional parameters ($1,$2,etc); the parameters in the EXECUTE are values.

If the prepared plan is different to the one-off plan, you can set PgJDBC’s prepare threshold via connection parameters to tell it never to use server-side prepared statements.

This difference between the plans of prepared and unprepared statements should go away in PostgreSQL 9.2. It’s been a long-standing wart, but Tom Lane dealt with it for the up-coming release.