Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Patryk Sidzina <patryk(dot)sidzina(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
Date: 2012-12-12 00:38:31
Message-ID: 2350.1355272711@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Tue, Dec 11, 2012 at 2:50 AM, Patryk Sidzina
> <patryk(dot)sidzina(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2012-12-12 01:03:14 Re: Do I have a hardware or a software problem?
Previous Message Jeff Janes 2012-12-11 23:53:47 Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?