Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 5EC3FC4CD7A for ; Thu, 3 May 2012 10:05:55 -0300 (ADT) Received: from kc8onw.net ([206.55.209.81] helo=mail.kc8onw.net) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvjG-0002yr-7c for pgsql-performance@postgresql.org; Thu, 03 May 2012 13:05:54 +0000 Received: from [10.70.3.194] (c-98-223-39-129.hsd1.in.comcast.net [98.223.39.129]) by mail.kc8onw.net (Postfix) with ESMTPSA id A5B0232ED7; Thu, 3 May 2012 09:05:40 -0400 (EDT) Message-ID: <4FA28299.1080805@kc8onw.net> Date: Thu, 03 May 2012 09:05:29 -0400 From: Jonathan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org, jturmel@gmail.com Subject: Re: Query got slow from 9.0 to 9.1 upgrade References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/26 X-Sequence-Number: 46850 On 4/30/2012 5:17 PM, Josh Turmel wrote: > We just upgraded from 9.0 to 9.1, we're using the same server > configuration, that has been confirmed 3 or 4 times over. Any help would > be appreciated. If I remove the "ORDER BY" it gets fast again because it > goes back to using the user_id index, if I remove the LIMIT/OFFSET it > gets fast again, obviously I need both of those, but that was just to > test and see what would happen. I had this problem as well and ended up working around it by having the application cache the highest seen user_id and send that back to the server which uses it in a where clause. This way I had just the LIMIT and was able to remove the OFFSET and things ran great. I don't know how feasible it is for you to change things application side but it worked well for me. Jonathan