Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZoQqv-0007yK-IJ for pgsql-performance@arkaria.postgresql.org; Tue, 20 Oct 2015 06:56:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZoQqv-0005WT-0I for pgsql-performance@arkaria.postgresql.org; Tue, 20 Oct 2015 06:56:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZoQpG-0003gk-Ia for pgsql-performance@postgresql.org; Tue, 20 Oct 2015 06:55:14 +0000 Received: from plane.gmane.org ([80.91.229.3]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZoQpD-0000nY-31 for pgsql-performance@postgresql.org; Tue, 20 Oct 2015 06:55:14 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZoQpA-0003uh-Tc for pgsql-performance@postgresql.org; Tue, 20 Oct 2015 08:55:09 +0200 Received: from 185.40.248.10 ([185.40.248.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Oct 2015 08:55:08 +0200 Received: from spam_eater by 185.40.248.10 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Oct 2015 08:55:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Thomas Kellerer Subject: Re: SELECT slows down on sixth execution Date: Tue, 20 Oct 2015 08:55:02 +0200 Lines: 27 Message-ID: References: <561E068F.1040702@socialserve.com> <561E749D.4090301@socialserve.com> <5621AF0D.5080203@socialserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 185.40.248.10 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 In-Reply-To: <5621AF0D.5080203@socialserve.com> X-Pg-Spam-Score: -1.4 (-) 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 Jonathan Rogers schrieb am 17.10.2015 um 04:14: >>> Yes, I have been looking at both plans and can see where they diverge. >>> How could I go about figuring out why Postgres fails to see the large >>> difference in plan execution time? I use exactly the same parameters >>> every time I execute the prepared statement, so how would Postgres come >>> to think that those are not the norm? >> >> PostgreSQL does not consider the actual query execution time, it only >> compares its estimates for there general and the custom plan. >> Also, it does not keep track of the parameter values you supply, >> only of the average custom plan query cost estimate. > > OK, that makes more sense then. It's somewhat tedious for the purpose of > testing to execute a prepared statement six times to see the plan which > needs to be optimized. Unfortunately, there doesn't seem to be any way > to force use of a generic plan in SQL based on Pavel Stehule's reply. If you are using JDBC the threshold can be changed: https://jdbc.postgresql.org/documentation/94/server-prepare.html https://jdbc.postgresql.org/documentation/publicapi/org/postgresql/PGStatement.html#setPrepareThreshold%28int%29 As I don't think JDBC is using anything "exotic" I would be surprised if this can't be changed with other programming environments also. Thomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance