Received: from u1.abs.net (root@u1.abs.net [207.114.0.131]) by hub.org (8.9.1/8.9.1) with ESMTP id LAA15313 for ; Wed, 27 Jan 1999 11:48:12 -0500 (EST) (envelope-from byronn@insightdist.com) Received: from insightdist.com (nobody@localhost) by u1.abs.net (8.9.0/8.9.0) with UUCP id LAA00481 for pgsql-interfaces@postgreSQL.org; Wed, 27 Jan 1999 11:19:16 -0500 (EST) X-Authentication-Warning: u1.abs.net: nobody set sender to insightdist.com!byronn using -f Received: from ceodev by insightdist.com (AIX 3.2/UCB 5.64/4.03) id AA45100; Wed, 27 Jan 1999 10:57:57 -0500 Received: from byronn by ceodev (AIX 4.1/UCB 5.64/4.03) id AA22020; Wed, 27 Jan 1999 10:57:56 -0500 Message-Id: <36AF37F9.7EFA27E1@insightdist.com> Date: Wed, 27 Jan 1999 10:59:53 -0500 From: Byron Nikolaidis X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 To: Hiroshi Inoue Cc: pgsql-interfaces Subject: Re: [INTERFACES] Use Declare/Fetch option References: <000201be49dd$05fe3b20$2801007e@cadzone.tpf.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroshi Inoue wrote: > Hello all, > > I have a question about psqlodbc driver. > Now the default setting for "Use Declare/Fetch" is false. > > In MVCC thanks to Vadim,readers block no writers. > So we can change the [Use Declare/Fetch] option to true ? > And if so,it's effective ? > All you say is correct. It probably could go back to true. But I think some people would probably prefer it stay false, because there is more odbc functionality provided with this setting. For example, when the option is false, the entire SQLExtendedFetch functionality is supported (prev,first,last,next,absolute,relative,bookmark). When the Declare/Fetch option is true, only fetch "next" is supported. There are more things like this. If you have extremely large result sets, then setting the option to true would prevent the driver from sucking down all your memory. And when the MVCC is available, the problem of locking rows won't be a problem anymore. For small to medium result sets, setting the option to false will probably result in faster performance. A future enhancement I have in mind for the driver is using both memory and files for caching large result sets and/or using a combination of both kinds of tuple access. Byron > Thanks. > > Hiroshi Inoue > Inoue@tpf.co.jp