Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TiaLN-00054H-3r for pgsql-performance@arkaria.postgresql.org; Wed, 12 Dec 2012 00:38:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TiaLM-00042d-5U for pgsql-performance@arkaria.postgresql.org; Wed, 12 Dec 2012 00:38:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TiaLL-00042X-62 for pgsql-performance@postgresql.org; Wed, 12 Dec 2012 00:38:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TiaLJ-0002gp-Aa for pgsql-performance@postgresql.org; Wed, 12 Dec 2012 00:38:34 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id qBC0cV0G002351; Tue, 11 Dec 2012 19:38:31 -0500 (EST) From: Tom Lane To: Jeff Janes cc: Patryk Sidzina , pgsql-performance@postgresql.org Subject: Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? In-reply-to: References: Comments: In-reply-to Jeff Janes message dated "Tue, 11 Dec 2012 15:53:47 -0800" Date: Tue, 11 Dec 2012 19:38:31 -0500 Message-ID: <2350.1355272711@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) 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 Jeff Janes writes: > On Tue, Dec 11, 2012 at 2:50 AM, Patryk Sidzina > wrote: >> The differences come up when you change the "INSERT" to "EXECUTE 'INSERT'" ( >> and i checked this time on 3 machines, one of which was Windows): >> FOR i IN 1..cnt LOOP >> EXECUTE 'INSERT INTO test_table_md_speed(n) VALUES (' || i || ')'; >> END LOOP; > The culprit is the commit below. I don't know exactly why this slows > down your case. A preliminary oprofile analysis suggests that it most > of the slowdown is that it calls AllocSetAlloc more often. I suspect > that this slow-down will be considered acceptable trade-off for > getting good parameterized plans. I'm having a hard time getting excited about optimizing the above case: the user can do far more to make it fast than we can, simply by not using EXECUTE, which is utterly unnecessary in this example. Having said that, though, it's not real clear to me why the plancache changes would have affected the speed of EXECUTE at all --- the whole point of that command is we don't cache a plan for the query. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance