Re: ECPG patch to use prepare for improved performance - Mailing list pgsql-patches

From Michael Meskes
Subject Re: ECPG patch to use prepare for improved performance
Date
Msg-id 20070510100044.GB409@feivel.credativ.de
Whole thread Raw
In response to Re: ECPG patch to use prepare for improved performance  ("William Lawrance" <bill.lawrance@bull.com>)
Responses Re: ECPG patch to use prepare for improved performance
List pgsql-patches
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
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

pgsql-patches by date:

Previous
From: "Jaime Casanova"
Date:
Subject: Re: [WIP] GUC for temp_tablespaces
Next
From: Andrew Dunstan
Date:
Subject: Re: updated WIP: arrays of composites