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
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? |