Thank you all for your prompt replies.
I tried about all the versions I could find (ranging from 7.3.200 to
till 8.1.1.03) and they all gave the same trouble.
Then I tried the latest snapshot, 8.1.1.04,and youhouuuuu, it worked!!!
Me a very happy man.
I'm not sure what you did we these dlls, but I just pulled in a +/- 25
milj row table in sas through the odbc (is against a postgresql 8.0.3
amd64 on freebsd 6.0) and it worked perfectly. Memory consumption never
went over 45M in windows. The table takes up 8.6GB of harddisk space in
Just for future references (in case someone ever has the same error), I
used the following settings:
with the following options:
- disable genetic optimizer
- Recognize Uniq Index
- Use Declare/Fetch
- Inknown sizes: max
- Bools as char
- maxvarchar: 254
- cache: 100
- max long varchar: 8190
- systableprefixes: dd_;
- show system tables
- LF <-> CR/LF
- row versioning
- int8 as default
- protocol >= 6.4
- OID options: show column & fake index
Tomas Skäre wrote:
> Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
>> I know about this limitation. There is problem ODBC keep all rows
>> in memory (+ result from libpq = 2 x result). Please try check
>> Use Declare/Fetch option. There is no twice result in memory in psqlODBC.
>> If it doesn't help you can try older releases which mayde do not do this.
>> Please try 8.00.X or even 7.03.209 (if you find it somewhere).
>> I know we're suggesting 8.01.X but few people work with so big
> Does it keep everything in memory when using cursors too?
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
In response to
pgsql-odbc by date
|Next:||From: frank||Date: 2005-12-13 17:58:45|
|Subject: client encoding mismatch help!|
|Previous:||From: Ludek Finstrle||Date: 2005-12-13 15:53:09|
|Subject: Re: Out of memory troubles with version 8.01.01.02|