Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id DBAC4BEAE5C for ; Wed, 25 Jul 2012 13:39:24 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Su4cO-0000yk-6k for pgsql-performance@postgresql.org; Wed, 25 Jul 2012 16:39:24 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6PGdAbh027538; Wed, 25 Jul 2012 12:39:10 -0400 (EDT) From: Tom Lane To: Marcus Engene cc: pgsql-performance@postgresql.org Subject: Re: odd planner again, pg 9.0.8 In-reply-to: <50101269.2020209@engene.se> References: <50101269.2020209@engene.se> Comments: In-reply-to Marcus Engene message dated "Wed, 25 Jul 2012 17:36:09 +0200" Date: Wed, 25 Jul 2012 12:39:09 -0400 Message-ID: <27536.1343234349@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/329 X-Sequence-Number: 47510 Marcus Engene writes: > Lacking index hints I have a bit of a problem with a slow select. I don't think you need index hints. What you probably do need is to increase join_collapse_limit and/or from_collapse_limit to deal with this complex query as a whole. > There are several selects looking similar to this in our application > that suddenly jumped from a handfull of ms to many seconds. Perhaps you had those settings adjusted properly and somebody turned them off again? regards, tom lane