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?



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:[EMAIL PROTECTED]
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

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.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to