X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 535409DCAA8 for ; Mon, 5 Dec 2005 10:32:53 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 61661-06 for ; Mon, 5 Dec 2005 10:32:57 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 28C899DCAA5 for ; Mon, 5 Dec 2005 10:32:50 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jB5EWr3O029238; Mon, 5 Dec 2005 09:32:54 -0500 (EST) To: "Markus Wollny" cc: pgsql-performance@postgresql.org Subject: Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0 In-reply-to: <28011CD60FB1724DBA4442E38277F6264A69CD@hermes.computec.de> References: <28011CD60FB1724DBA4442E38277F6264A69CD@hermes.computec.de> Comments: In-reply-to "Markus Wollny" message dated "Mon, 05 Dec 2005 11:28:54 +0100" Date: Mon, 05 Dec 2005 09:32:53 -0500 Message-ID: <29237.1133793173@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/122 X-Sequence-Number: 15943 "Markus Wollny" writes: >> ... What I find interesting though is >> that the plain index scan in 8.0 is so enormously cheaper >> than it's estimated to be. Perhaps the answer table in your >> 8.0 installation is almost perfectly ordered by session_id? > Not quite - there may be several concurrent sessions at any one time, but ordinarily the answers for one session-id would be quite close together, in a lot of cases even in perfect sequence, so "almost perfectly" might be a fair description, depending on the exact definition of "almost" :) Could we see the pg_stats row for answer.session_id in both 8.0 and 8.1? > I had set random_page_cost to 1.4 already, so I doubt that it would do much good to further reduce the value - reading the docs and the suggestions for tuning I would have thought that I should actually consider increasing this value a bit, as not all of my data will fit in memory any more. Do you nevertheless want me to try what happens if I reduce random_page_cost even further? No, that's probably quite low enough already ... regards, tom lane