Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id A83F0B5DC1A
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue,  1 Nov 2011 10:43:07 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 28776-01
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue,  1 Nov 2011 13:43:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 63703B5DC10
	for <pgsql-performance@postgresql.org>;
	Tue,  1 Nov 2011 10:43:01 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pA1Dh0xu024831;
	Tue, 1 Nov 2011 09:43:00 -0400 (EDT)
To: Marcus Engene <mengpg2@engene.se>
cc: pgsql-performance@postgresql.org
Subject: Re: Performance Problem with postgresql 9.03, 8GB RAM,
	Quadcore Processor Server--Need help!!!!!!!
In-reply-to: <4EAFC29A.40509@engene.se> 
References: 
 <CACBfhZPO1GJv4nVunPXGA2EZq923On-CBGtxyhtQYAaSMCuBEQ@mail.gmail.com>
	<CAF-3MvOjY17pVZXSWgYDB5dMy-B07KiVYexR4RRutxZyXeKjbA@mail.gmail.com>
	<CACBfhZNBwjB=3xQrvqy6ManJUaRyKEOoV8dMv7jJYPtXn9XFcQ@mail.gmail.com>
	<CACBfhZNr5qnMN0=8hp1Fb3hA8jwoEXnJAahua1JT5f5gXT9tuA@mail.gmail.com>
	<4EAFC29A.40509@engene.se>
Comments: In-reply-to Marcus Engene <mengpg2@engene.se>
	message dated "Tue, 01 Nov 2011 10:57:46 +0100"
Date: Tue, 01 Nov 2011 09:43:00 -0400
Message-ID: <24830.1320154980@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-3.101 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-1.201
X-Spam-Level: 
X-Archive-Number: 201111/5
X-Sequence-Number: 45516

Marcus Engene <mengpg2@engene.se> writes:
> After I upgraded from Postgres 8.3/8.4 to 9.0 I had all sorts of 
> problems with queries with many joins. Queries that used to take 1ms 
> suddenly take half a minute for no apparent reason.

Could we see a concrete test case, rather than hand waving?  If there's
really a problem in 9.0, it's impossible to fix it on so little detail.

> One workaround I've done is if something looking like this....

The only way that should make a difference is if the total number
of tables in the query exceeds from_collapse_limit (or maybe
join_collapse_limit, depending on exactly how you wrote the query).
Perhaps you'd been running with nonstandard values of those settings
in 8.x, and forgot to transfer them into the new DB?

			regards, tom lane