R: Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").

From: "Cristiano Ansaloni" <ans(at)prosystem(dot)it>
To: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, <pgsql-bugs(at)postgresql(dot)org>
Subject: R: Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").
Date: 2005-11-10 09:08:58
Message-ID: 18878996A52ABE46B181C042831FB1621B468F@diana.2kpro.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs



_____

From: pgsql-bugs-owner(at)postgresql(dot)org
[mailto:pgsql-bugs-owner(at)postgresql(dot)org] On Behalf Of Cristiano Ansaloni
Sent: 08 November 2005 15:35
To: pgsql-bugs(at)postgresql(dot)org
Subject: [BUGS] Psql odbc driver version 8.01.01.00 doesn't
remember "Cache size" option if it is set to 0 (to set "unlimited").

Psql odbc driver version 8.01.01.00 doesn't remember "Cache
size" option if it is set to 0 (to set "unlimited").

Cache size of 0/unlimited makes no sense. The cache is only used in
declare/fetch mode, so if you want to fetch all rows at once, just turn
off use declare/fetch.

Instead, the "Maximum rows to retrieve" option in the Tab 3 of
pgAdmin options works good.

pgAdmin III doesn't use ODBC, and besides, that option is not analagous
to psqlODBC's cache size setting in the slightest. I would suggest
reading the appropriate doc pages for each product.

I have read the documentation:

Use Declare/Fetch: If true, the driver automatically uses declare
cursor/fetch to handle SELECT statements and keeps 100 rows in a cache.
This is mostly a great advantage, especially if you are only interested
in reading and not updating. It results in the driver not sucking down
lots of memory to buffer the entire result set. If set to false, cursors
will not be used and the driver will retrieve the entire result set. For
very large tables, this is very inefficient and may use up all the
Windows memory/resources. However, it may handle updates better since
the tables are not kept open, as they are when using cursors. This was
the style of the old podbc32 driver. However, the behavior of the memory
allocation is much improved so even when not using cursors, performance
should at least be better than the old podbc32.

The problem is that this documentation says the opposite of true: with
this option false (the default) there is the 100 rows limit, with this
option true the cursor is "free". I have tested it.

Moreover, this "new" default change the "old" default and so all "old
configurations" odbc are wrong.

Sorry for my english.

Regards, Ans.

Browse pgsql-bugs by date

  From Date Subject
Next Message Neeraj Malhotra 2005-11-10 12:10:27 BUG #2034: Wrong time zone IST
Previous Message Mark Gibson 2005-11-10 08:31:18 Re: BUG #2031: Patch also required prior to ML3