Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
Date
Msg-id 2350.1355272711@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance
Jeff Janes <jeff.janes@gmail.com> writes:
> On Tue, Dec 11, 2012 at 2:50 AM, Patryk Sidzina
> <patryk.sidzina@gmail.com> 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


pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
Next
From: Craig Ringer
Date:
Subject: Re: Do I have a hardware or a software problem?