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:[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
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
---------------------------(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
match
