Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 7C52A2E0033 for ; Thu, 29 May 2008 13:53:57 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 96451-05 for ; Thu, 29 May 2008 13:53:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by developer.postgresql.org (Postfix) with ESMTP id 609AC2E0030 for ; Thu, 29 May 2008 13:53:53 -0300 (ADT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAEx8PkjLevdH/2dsb2JhbAAsgSmuGw X-IronPort-AV: E=Sophos;i="4.27,562,1204464600"; d="scan'208";a="113971635" Received: from ppp247-71.static.internode.on.net (HELO DevBox.local) ([203.122.247.71]) by ipmail01.adl6.internode.on.net with ESMTP; 30 May 2008 02:23:49 +0930 Message-ID: <483EDF9A.20100@Sheeky.Biz> Date: Fri, 30 May 2008 02:23:46 +0930 From: Shane Ambler User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Chris Shoemaker CC: pgsql-performance@postgresql.org, ejones@engineyard.com Subject: Re: Adding "LIMIT 1" kills performance. References: <20080529154734.GA18273@pe.Belkin> In-Reply-To: <20080529154734.GA18273@pe.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/371 X-Sequence-Number: 30339 Chris Shoemaker wrote: > [Attn list-queue maintainers: Please drop the earlier version > of this email that I accidentally sent from an unsubscribed address. ] > > Hi, > > I'm having a strange problem with a slow-running select query. The > query I use in production ends in "LIMIT 1", and it runs very slowly. > But when I remove the "LIMIT 1", the query runs quite quickly. This > behavior has stumped a couple smart DBAs. > > Can anyone explain why such a slow plan is chosen when the "LIMIT 1" > is present? Is there anything I can do to speed this query up? > Thanks. > From what I know using an ORDER BY and a LIMIT can often prevent *shortening* the query as it still needs to find all rows to perform the order by before it limits. The difference in plans eludes me. > production=> EXPLAIN ANALYZE SELECT event_updates.* > FROM event_updates > INNER JOIN calendars ON event_updates.feed_id = calendars.id > INNER JOIN calendar_links ON calendars.id = calendar_links.source_tracker_id > WHERE (calendar_links.calendar_group_id = 3640) > ORDER BY event_updates.id DESC > LIMIT 1; Does removing the DESC from the order by give the same variation in plans? Or is this only when using ORDER BY ... DESC LIMIT 1? One thing that interests me is try - EXPLAIN ANALYZE SELECT * FROM ( SELECT event_updates.* FROM event_updates INNER JOIN calendars ON event_updates.feed_id = calendars.id INNER JOIN calendar_links ON calendars.id = calendar_links.source_tracker_id WHERE (calendar_links.calendar_group_id = 3640) ORDER BY event_updates.id DESC ) AS foo LIMIT 1; -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz