Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQk7v-0007z4-8c for pgsql-performance@arkaria.postgresql.org; Fri, 12 Apr 2013 19:59:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UQk7u-0000ih-HM for pgsql-performance@arkaria.postgresql.org; Fri, 12 Apr 2013 19:59:14 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQk7t-0000iW-8g for pgsql-performance@postgresql.org; Fri, 12 Apr 2013 19:59:13 +0000 Received: from smtp.optionshouse.com ([38.98.137.6] helo=smtp.peak6.com) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQk7m-0000fc-JH for pgsql-performance@postgresql.org; Fri, 12 Apr 2013 19:59:12 +0000 X-AuditID: 0a64cb20-b7f4d6d000005ea5-7d-516867891fee Message-ID: <51686787.3050308@optionshouse.com> Date: Fri, 12 Apr 2013 14:59:03 -0500 From: Shaun Thomas Reply-To: Organization: Peak6 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: brick pglists CC: Subject: Re: Changing ORDER BY column slows query dramatically References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.201.64] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsXClcIrptuZnhFoMPG3iMWelTuZLK7PPMfs wOSxc9Zddo8L+6axBzBFNTDaJObl5ZcklqQqpKQWJ9sq+ReUZObnFXvklxanKrhkFifnJGbm phYpKWSm2CoZKykU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJbt4ZJDQyZLxYCtbwX3OirM/lrA1ML5g72Lk5JAQMJFoW3yZGcIWk7hwbz0biM0r oC+xf8kqRhCbRUBV4s26qWA2m4CuxKT+FWA1QgIqEn1nbzCB2PwCwhL7PjSBzREVCJPYe2Ea 1BxBiZMzn7CA2CICWhJ7N3WB1TMLqEnMfTiJFcQWFvCQ+H/9HFCcA2hmgMT6/hAQk1MgUKLz nD9Eta3EhTnXWSBseYntb+cwQ1ygKrGieSIbxPUKEv+vvGOawCg0C8niWUjaZyFpX8DIvIpR vLgsMTkj07SgOLekwEivIDUx20wvL7VkEyM4Zk8r7GD83ml1iFGAg1GJh7dAMSNQiDWxrLgy 9xCjBAezkgjvuTigEG9KYmVValF+fFFpTmrxIUYfYIhNZJYSTc4HppO8knhDY1MDU0tTQ1Nz U0MjHMJK4ryGiyMDhQTSgUkkOzW1ILUIZhwTB6dUA2PW7amTlzscszS48vkC69FLqpv6/vKv bjvkdaTrVLbrQ3WRs3Y7DhW8t298mzXlnCrblitvbDmZ47b75l17qXhtEUNX3uPldUeEzW5e YWXUWGO61lhQyKD/A8vdzHtJgvc/bhFjTTtTeaLylKLZBFv5JK/Ia0fWGFw1tzlsOX1+qrlF 7ZbtnYuVWIozEg21mIuKEwFQ2o2/BgMAAA== X-Pg-Spam-Score: -4.3 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 04/12/2013 11:51 AM, brick pglists wrote: > -> Index Scan Backward using event_20130405_id_pk on > event_20130405 e (cost=0.00..612732.34 rows=1889715 width=34) (actual > time=2076.812..2111.274 rows=10100 loops=1) > Filter: ((tstamp_utc >= '2013-04-05 > 10:00:00'::timestamp without time zone) AND (tstamp_utc <= '2013-04-05 > 18:00:00'::timestamp without time zone) AND (date_utc = > '2013-04-05'::date) AND (org_id = 216471)) This right here is your culprit. The planner thinks it'll be faster to grab 100 rows by scanning your primary key backwards and filtering out the matching utc timestamps and other criteria. Since it doesn't show up in your GUC list, you should probably increase your default_statistics_target to 400 or more, analyze, and try again. The heuristics for the dates aren't complete enough, so it thinks there are few matches. If that doesn't work and you want a quick, but ugly fix for this, you can create the following index: CREATE INDEX event_20130406_id_desc_tstamp_utc_idx ON event_20130406 (id DESC, tstamp_utc); -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance