Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WsBg7-00060v-7w for pgsql-performance@arkaria.postgresql.org; Wed, 04 Jun 2014 13:56:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WsBg6-0000AT-48 for pgsql-performance@arkaria.postgresql.org; Wed, 04 Jun 2014 13:56:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1WsBfx-0008MP-19 for pgsql-performance@postgresql.org; Wed, 04 Jun 2014 13:56:21 +0000 Received: from ns3099999.ip-37-59-8.eu ([37.59.8.46] helo=mail.linos.es) by makus.postgresql.org with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WsBfq-00042g-Oc for pgsql-performance@postgresql.org; Wed, 04 Jun 2014 13:56:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.linos.es (Postfix) with ESMTP id 9D9056080700 for ; Wed, 4 Jun 2014 15:56:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ns3099999.ip-37-59-8.eu Received: from mail.linos.es ([37.59.8.46]) by localhost (ns3099999.ip-37-59-8.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYnczc5oJ-wI for ; Wed, 4 Jun 2014 15:56:09 +0200 (CEST) Received: from [192.168.254.106] (47.Red-88-6-73.staticIP.rima-tde.net [88.6.73.47]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: info@linos.es) by mail.linos.es (Postfix) with ESMTPSA id 342C86080225 for ; Wed, 4 Jun 2014 15:56:09 +0200 (CEST) Message-ID: <538F2578.9080001@linos.es> Date: Wed, 04 Jun 2014 15:56:08 +0200 From: Linos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: Possible performance regression in PostgreSQL 9.2/9.3? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -0.5 (/) 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 Hello, Some days ago I upgraded from 8.4 to 9.3, after the upgrade some queries started performing a lot slower, the query I am using in this example is pasted here: http://pastebin.com/71DjEC21 Considering it is a production database users are complaining because queries are much slower than before, so I tried to downgrade to 9.2 with the same result as 9.3, I finally restored the database on 8.4 and the query is as fast as before. All this tests are done on Debian Squeeze with 2.6.32-5-amd64 kernel version, the hardware is Intel Xeon E5520, 32Gb ECC RAM, the storage is software RAID 10 with 4 SEAGATE ST3146356SS SAS drives. postgresql.conf: max_connections = 250 shared_buffers = 6144MB temp_buffers = 8MB max_prepared_transactions = 0 work_mem = 24MB maintenance_work_mem = 384MB max_stack_depth = 7MB default_statistics_target = 150 effective_cache_size = 24576MB 9.3 explain: http://explain.depesz.com/s/jP7o 9.3 explain analyze: http://explain.depesz.com/s/6UQT 9.2 explain: http://explain.depesz.com/s/EW1g 8.4 explain: http://explain.depesz.com/s/iAba 8.4 explain analyze: http://explain.depesz.com/s/MPt It seems to me that the total estimated cost went too high in 9.2 and 9.3 but I am not sure why, I tried commenting out part of the query and disabling indexonlyscan but still I have very bad timings and estimates. The dump file is the same for all versions and after the restore process ended I did vacuum analyze on the restored database in all versions. Regards, Miguel Angel. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance