Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id A27F064FD11 for ; Mon, 28 Jul 2008 05:46:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 39010-02 for ; Mon, 28 Jul 2008 05:46:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from www.postnewspapers.com.au (www.postnewspapers.com.au [202.61.230.242]) by postgresql.org (Postfix) with ESMTP id 1FEE264FCE3 for ; Mon, 28 Jul 2008 05:46:17 -0300 (ADT) Received: from mail.postnewspapers.com.au (202-89-185-120.static.dsl.amnet.net.au [202.89.185.120]) by www.postnewspapers.com.au (Postfix) with ESMTP id BD87C5C0E4; Mon, 28 Jul 2008 16:46:12 +0800 (WST) Received: from [10.0.0.53] (wallace.localnet [10.0.0.53]) by mail.postnewspapers.com.au (Postfix) with ESMTP id A5CD11E0434; Mon, 28 Jul 2008 16:46:12 +0800 (WST) Message-ID: <488D8754.2010208@postnewspapers.com.au> Date: Mon, 28 Jul 2008 16:46:12 +0800 From: Craig Ringer User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: =?ISO-8859-2?Q?Faludi_G=E1bor?= Cc: pgsql-performance@postgresql.org Subject: Re: how does pg handle concurrent queries and same queries References: <000301c8f07d$4bee0f10$e3ca2d30$@hu> In-Reply-To: <000301c8f07d$4bee0f10$e3ca2d30$@hu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/235 X-Sequence-Number: 30835 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