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

[ psqlodbc-Bugs-1000604 ] 8.01.0200 slow with long queries

From: <noreply(at)pgfoundry(dot)org>
To: noreply(at)pgfoundry(dot)org
Subject: [ psqlodbc-Bugs-1000604 ] 8.01.0200 slow with long queries
Date: 2006-04-28 08:22:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
Bugs item #1000604, was opened at 2006-04-04 10:45
You can respond by visiting:

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Lasse Haataja (lhaataja)
Assigned to: Nobody (None)
Summary: 8.01.0200 slow with long queries

Initial Comment:
psqlodbc 8.01.0200 is much slower than 8.01.0102 (and earlier versions)
with long (>10 kilobytes) queries; a 1 megabyte query that takes two
seconds with .0102 takes 37 minutes with .0200.
According to mylog, most of the time seems to be taken by PGAPI_NumParams.
(Although bind.c seems to be identical in .0102 and .0200, perhaps the
arguments the function is called with makes the difference?)
The culprit seems likely to be the line
for (i = 0; i < strlen(stmt->statement); i++)
where strlen is (needlessly, since the string is not modified, let alone
its length changed) evaluated once for each iteration of the loop, resulting
in O(N^2) complexity. Fix should be easy, something along the lines of
size_t stmt_len = strlen(stmt->statement);
for (i = 0; i < stmt_len; i++)
The same problem occurs in misc.c function remove_newlines(); the same fix
appears applicable there as well.


Comment By: Lasse Haataja (lhaataja)
Date: 2006-04-05 07:28

This is fixed in 07.03.0260 (The strlen evaluated every
iteration is still present in the source in
remove_newlines(), but the function doesn't seem to be used
at all, so no problem there).


You can respond by visiting:

pgsql-odbc by date

Next:From: noreplyDate: 2006-04-28 08:23:10
Subject: [ psqlodbc-Bugs-1000413 ] Optimistic lock cannot be used with updateable cursors
Previous:From: Philippe LangDate: 2006-04-28 07:50:59
Subject: Re: PG 8 INOUT parameters & ADO

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