Re: ECPG patch to use prepare for improved performance

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: William Lawrance <bill(dot)lawrance(at)bull(dot)com>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, Pgsql-Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: ECPG patch to use prepare for improved performance
Date: 2007-05-10 22:00:07
Message-ID: 464395E7.6040204@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


This seems like a very all or nothing approach. By contrast, the Perl
DBD::Pg driver lets you decide per statement if you want it
server-prepared or not. Is that not possible?

cheers

andrew

William Lawrance wrote:
> This updated patch for ECPG uses the current routines by
> default. If an environment variable (ECPGUSEPREPARE) is set
> to "yes", it uses the new routine that prepares and
> caches each statement.
>
>
>
>
> -----Original Message-----
> From: Michael Meskes [mailto:meskes(at)postgresql(dot)org]
> Sent: Thursday, May 10, 2007 3:01 AM
> To: William Lawrance
> Cc: Michael Meskes; Pgsql-Patches
> Subject: Re: [PATCHES] ECPG patch to use prepare for improved
> performance
>
>
> On Wed, May 09, 2007 at 01:12:17PM -0700, William Lawrance wrote:
>
>> 2. The performance was improved by about 1 hour in the 3 hour
>> elapsed time of the application. This is important to the
>> customer in terms of accomplishing his work load in the
>> time that has been allotted, based on his experience with DB2.
>> Without this improvement, he is likely to consider it too slow.
>>
>
> But this only holds for one customer. I don't think this will hold for
> every single application. At least I do not see a reason why this
> should hold everytime.
>
>
>> I would like to emphasize that we aren't measuring an artificial
>> test program; this is a real customer's application. We loaded
>> 7 million rows into 217 tables to run the application. I believe
>> it is representative of many real batch applications.
>>
>
> But how about non-batch applications?
>
>
>> Is there reason not to prepare each statement?
>>
>
> I'm completely against forcing such a design decision on the programmer.
> Hopefully I will be able to add a real prepare statement soon.
>
>
>> Could it be predicated upon a user supplied option ?
>>
>
> Yes, this is fine with me. If you could rearrange the patch I will test
> and commit it.
>
> Michael
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2007-05-11 10:01:38 Re: Logging checkpoints and other slowdown causes
Previous Message William Lawrance 2007-05-10 21:54:39 Re: ECPG patch to use prepare for improved performance