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

Re: Deallocation speed

From: Mark Simonetti <marks(at)opalsoftware(dot)co(dot)uk>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Deallocation speed
Date: 2010-04-13 13:39:49
Message-ID: 4BC47425.40003@opalsoftware.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc
On 13/04/2010 14:03, Hiroshi Inoue wrote:
> Mark Simonetti wrote:
>> Hi,
>> I'm currently working on a c++ project that uses the psqlodbc driver.
>>
>> I have a query that returns over 26000 rows, and about 45 columns.
>>
>> When it comes to closing the statement using SQLFreeStmt(hstmt, 
>> SQL_CLOSE), the command seems to take about 70 seconds to return (on 
>> a 3.16ghz processor!).   This just doesn't seem right.  Is there 
>> something I may be missing?
>
> Aren't you turning on the mylog option?
>
> regards,
> Hiroshi Inoue
>
>

No, the log is not turned on.  I turned it on temporarily to see if it 
contained any useful information regarding the problem.

Interestingly, if I do not run the program from the Visual Studio IDE, 
the problem goes away.  The problem only seems to exist if I run the 
program in the Visual Studio IDE in either Debug or Release mode.

If I enable UseDeclareFetch in the psqlODBC connection string the 
problem also goes away, indicating it is indeed a something that occurs 
while psqlODBC is freeing up memory from a large set of data - so maybe 
it is Visual Studio is hooking into the memory allocation/deallocation 
of the psqlODBC?

I can now at least work round the problem while using the IDE, and not 
worry at all about the problem in production as it does not then occur.

I'm still surprised it happens though!

Mark.


In response to

pgsql-odbc by date

Next:From: WILLIAM MENDEZDate: 2010-04-13 21:05:29
Subject: solicitud de archivo
Previous:From: Hiroshi InoueDate: 2010-04-13 13:03:47
Subject: Re: Deallocation speed

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