Skip site navigation (1) Skip section navigation (2)

Re: Improve ODBC Throughput ?

From: Arnaud Lesauvage <thewild(at)freesurf(dot)fr>
To: Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Improve ODBC Throughput ?
Date: 2006-10-20 08:52:34
Message-ID: 45388E52.6040800@freesurf.fr (view raw or flat)
Thread:
Lists: pgsql-odbc
Ludek Finstrle a écrit :
>> >2.Declare Fetch
>> >In Access, you do not have this fine control. Some psqlODBC user have
>> >experimented with the DECLARE/FETCH option in the psqlODBC settngs.I am not
>> >entirely sure how Declare/Fetch works though, I have never used it.
>> 
>> My tables are linked with these options :
>> UseDeclareFetch=1
>> UseServerSidePrepare=1
>> Fetch=10000
> 
> UseDeclareFetch and UseServerSidePrepare are disjoint options.
> If I remember it the right way the UseServerSidePrepare disallow
> UseDeclareFetch. Please try UseServerSidePrepare=0 when you want
> using DeclareFetch.
> 
> Why you set Fetch so high? How many rows do you expect?
> The UseDeclareFetch declare the select statement as cursor (using
> declare statement) and then get the rows using fetch statement
> (see postgresql manual).
> I see no usage for UseDeclareFetch with so high Fetch.
> 
> The UseServerSidePrepare use prepare and execute statement (also
> see postgresql manual).

I thought that since memory consumption was not an issue, I 
could fetch a lot of rows at once. I read the ODBC 
documentation about that but not PostgreSQL's, but I'll 
correct this ASAP.

What is your advice in fact ?

UseDeclareFetch=0
UseServerSidePrepare=1

Or maybe

UseDeclareFetch=1
UseServerSidePrepare=0
Fetch=100


I might just try both in fact (don't have the time right 
now, maybe later today though).

In response to

Responses

pgsql-odbc by date

Next:From: Ludek FinstrleDate: 2006-10-20 09:11:52
Subject: Re: Improve ODBC Throughput ?
Previous:From: Arnaud LesauvageDate: 2006-10-20 08:49:34
Subject: Re: Improve ODBC Throughput ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group