Re: ECPG patch to use prepare for improved performance
От | Andrew Dunstan |
---|---|
Тема | Re: ECPG patch to use prepare for improved performance |
Дата | |
Msg-id | 464395E7.6040204@dunslane.net обсуждение исходный текст |
Ответ на | Re: ECPG patch to use prepare for improved performance ("William Lawrance" <bill.lawrance@bull.com>) |
Список | 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@postgresql.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 >
В списке pgsql-patches по дате отправления: