Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id B4340B5DC1B for ; Thu, 22 Sep 2011 20:15:04 -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 20703-10 for ; Thu, 22 Sep 2011 23:14:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from tamriel.snowman.net (tamriel.snowman.net [72.66.115.51]) by mail.postgresql.org (Postfix) with ESMTP id 5AF2CB5DC1A for ; Thu, 22 Sep 2011 20:14:57 -0300 (ADT) Received: by tamriel.snowman.net (Postfix, from userid 1000) id EBE11229F2; Thu, 22 Sep 2011 19:14:56 -0400 (EDT) Date: Thu, 22 Sep 2011 19:14:56 -0400 From: Stephen Frost To: Michael Viscuso Cc: Tom Lane , Greg Smith , pgsql-performance@postgresql.org Subject: Re: Query optimization using order by and limit Message-ID: <20110922231456.GN12765@tamriel.snowman.net> References: <4E7A93F9.1050301@2ndQuadrant.com> <6768.1316657361@sss.pgh.pa.us> <4E7AA399.6000209@getcarbonblack.com> <20110922145319.GJ12765@tamriel.snowman.net> <4E7BBCF3.4080502@getcarbonblack.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8KlXS1coelMGD729" Content-Disposition: inline In-Reply-To: <4E7BBCF3.4080502@getcarbonblack.com> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.32-5-amd64 (x86_64) X-Uptime: 19:06:02 up 232 days, 7:36, 13 users, load average: 0.01, 0.04, 0.00 User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/350 X-Sequence-Number: 45126 --8KlXS1coelMGD729 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mike, * Michael Viscuso (michael.viscuso@getcarbonblack.com) wrote: > I spent the better part of the day implementing an application layer > nested loop and it seems to be working well. Of course it's a little > slower than a Postgres only solution because it has to pass data back > and forth for each daily table query until it reaches the limit, but at > least I don't have "runaway" queries like I was seeing before. That > should be a pretty good stopgap solution for the time being. Glad to hear that you were able to get something going which worked for you. > I was really hoping there was a Postgres exclusive answer though! :) If > there are any other suggestions, it's a simple flag in my application to > query the other way again... I continue to wonder if some combination of multi-column indexes might have made the task of finding the 'lowest' record from each of the tables fast enough that it wouldn't be an issue. > Thanks for all your help - and I'm still looking to change those > numerics to bigints, just haven't figured out the best way yet. Our timestamps are also implemented using 64bit integers and would allow you to use all the PG date/time functions and operators. Just a thought. Thanks, Stephen --8KlXS1coelMGD729 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk57wXAACgkQrzgMPqB3kijaNwCfQ9cSdzzHyiPwa+BTzIihWR7T baoAoIbL8P3atU1cfbcCoFXFGbKE7fPt =ZRqu -----END PGP SIGNATURE----- --8KlXS1coelMGD729--