Avoid O(n^2) behavior with large parameter arrays - Mailing list pgsql-odbc

From Heikki Linnakangas
Subject Avoid O(n^2) behavior with large parameter arrays
Date
Msg-id 51435052.5060304@vmware.com
Whole thread Raw
List pgsql-odbc
While digging deeper into the array binding code, I noticed that a lot
of time is spent chasing the end of the linked list of query result, to
append a new result at the end. When executing a statement with array
binding, SC_execute iterates through all the previous results, leading
to O(n^2) behavior. With a large parameter array, a lot of CPU time is
spent doing that.

Attached patch fixes that by keeping track of the tail of the linked
list, and the StatementClass that "owns" each QResultClass object (if
any). By "owning", I mean that the QResultClass object is linked in the
linked list of that StatementClass. That avoids having to traverse the
list to check if a QResultClass is already in the chain.

With this patch, I'm no longer seeing O(n^2) behavior, and it becomes
feasible to use large parameter arrays with > 100000 elements.

(as usual, this patch is also available in my github repository)

- Heikki

Attachment

pgsql-odbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Migrating from CVS to git
Next
From: Ben Morgan
Date:
Subject: Bug: attributes dynamically filled (e.g. xml) truncated