Faludi Gábor wrote: > . Why does the second and the later queries take the whole on second > if the dataset is the same . Shouldn't PG realise that the query is the same > so i give the user the same resultset ?
That would require a result cache. I don't know if Pg even has a query result cache - I don't think so, but I'm not sure. Even if it does, it'd still only be useful if the queries were issued under *exactly* the same conditions - in other words, no writes had been made to the database since the cached query was issued, and the first query had committed before the second began (or was read-only). Additionally, no volatile functions could be called in the query, because their values/effects might be different when the query is executed a second time. That includes triggers, etc. Since 7.4 doesn't do lazy xid allocation it can't really tell that nothing has been changed since the previous query was cached. So, if I'm not missing something here, a query result cache would be useless anyway. > . How do I know if one query blocks the other ? Examination of pg_catalog.pg_locks is certainly a start. It's trickier with lots of short-running queries, though. > . Is there a way to log the long running queries in 7.4 ? If not is > it available in any newer version ? It's certainly available in 8.3, as log_min_duration_statement in postgresql.conf . You can find out if it's in 7.4, and if not what version it was introduced in, by looking through the documentation for versions 7.4 and up. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
