Hello, There are several things that I would like to point out:
1. Look no further than what happens for SELECTs. Data caching is turned on by default - and I have not heard much complaining about it. Perl is seldom used for user interface development and the scenario you describe is an exception rather than the norm. If turning on data caching by default was a good decision for SELECTs, then there is little reason not to turn on caching by default for REF CURSORs. 2. Nevertheless, in the patch I have kept data caching turned off by default for REF CURSORs so that users who are currently happy fetching a single row per DB roundtrip can remain in that state. Only if users set the caching parameter, multiple rows will be fetched per DB roundtrip. 3. Per-statement cache tuning may be done by setting the RefCursorCacheSize to an appropriate before executing/fetching from a REF CURSOR. This is just as you would do for RowCacheSize - which controls rows fetched per DB roundtrip for SELECTs (Set this to explicitly 1 and fetch a significant number of rows and you will realize that data caching is turned on by default for SELECT statement results). The reason I recommend this patch is that there is currently no way (that I am aware of) to improve performance of fetch from REF CURSORs in perl. I dont mind it being turned off by default - but at least users who want the efficiency will have an option to do so. Biswa On 9/19/07, Alexander V Alekseev <[EMAIL PROTECTED]> wrote: > > Hello! > > On Wed, 19 Sep 2007, Biswadeep Chowdhury wrote: > > > This patch speeds up both the regular fetch, as well as the > > fetchall_arrayref(). To me that seems better than ONLY speeding up > > fetchall_arrayref. > If application requires fast response (as typical user > interface does), you may slow down the process. If you fetch from > complex query, you may get the first row immediately, and the next > row may require a few seconds to calculate. So, if you fetch by 1 > row, you receive immediate response. If you fetch by 3 rows, you have to > wait for database to calculate 3 rows, before you get the response. > > As I understand DBD interface, there is fetchrow_... interface > for 1-row fetch, and fetchall_arrayref() for multi-rows fetch. > Am I right? > Data caching is a good idea, but it should be tuned > per-statement. Though I don't know the way to do it, as prepare() > doesn't accept any additional attributes. > > Bye. Alex. > >
