Skip to main content

Function call performance optimizations

On my last post about that subject, I wrote about some optimizations I did to get better performance when calling functions with Npgsql.

While that optimizations were very nice, they had a drawback: you had to reuse your NpgsqlCommand object. You had to reuse it because the optimizations were based on cached data and if you created a new NpgsqlCommand object the data would need to be cached again.

In the general case, where you would create many NpgsqlCommand objects and call functions with them, you would not benefit from those optimizations.

In order to fix that, Noah Misch created a patch which remove 2 of the 3 internal calls which were giving performance problems.

The only case left is for functions which have return type of 'record'. We are working to get this case also covered.

I'm going to show here how much performance improvement you get with this patch with a simple call to a function which returns an integer. This function is on Npgsql unit test suite, but I reproduce it here just for completeness:


create function funcA() returns int as '
select 0;

' language 'sql';




I'm going to compare the latest stable release version Npgsql 2.0.8 with our latest cvs version with Noah's patch.


In a loop of 100 iteractions, this is what we get with Npgsql 2.0.8 and Npgsql cvs:


Npgsql 2.0.8:

time mono teste.exe

real 0m0.537s
user 0m0.457s
sys 0m0.028s


Npgsql cvs:

time mono teste.exe

real 0m0.467s
user 0m0.420s
sys 0m0.026s



It is 13% faster!

If we raise the number of interactions to 1000 we get:


Npgsql 2.0.8:

time mono teste.exe

real 0m1.237s
user 0m0.698s
sys 0m0.089s


Npgsql cvs:

time mono teste.exe

real 0m0.655s
user 0m0.492s
sys 0m0.054s



Which gives 47% improvement!

So, when next Npgsql release is out, we can see a modest to good performance improvement in function calling scenarios using Npgsql.

If you want to try it out today, please grab the latest cvs code and let us know what do you get.

Please, leave your comments and feedback. Also, participate on our Forums so you can share your experience.

Comments

Popular posts from this blog

UUID datatype and COPY IN/OUT support added to cvs

Hi all! It was just added support to uuid datatype in cvs head. This type will be available in next Postgresql release 8.3. Thanks to David Bachmann for his patch! You can get more info about this patch in this mailing list post . Also was added support for copy in and copy out operations. Now, users can provide streams which can be copied directly to and from Postgresql tables! Thanks to Kalle Hallivuori for providing a patch! Thanks to Truviso for giving support to Kalle. More info about that including a demo and ready to use compiled Npgsql.dll versions can be found here . That's it! As soon as we get more features added, I will post info about them here. Stay tuned! :)

Npgsql Tips: Using " in (...)" queries with parameters list and "any" operator

Hi, all! We have received some users questions about how to send a list of values to be used in queries using the "in" operator. Something like: select foo, bar from table where foo in (blah1, blah2, blah3); Npgsql supports array-like parameter values and the first idea to have this working would try to use it directly: NpgsqlCommand command = new NpgsqlCommand("select * from tablee where field_serial in (:parameterlist)", conn); ArrayList l = new ArrayList(); l.Add(5); l.Add(6); command.Parameters.Add(new NpgsqlParameter("parameterlist", NpgsqlDbType.Array | NpgsqlDbType.Integer)); command.Parameters[0].Value = l.ToArray(); NpgsqlDataReader dr = command.ExecuteReader(); but unfortunately this won't work as expected. Npgsql will send a query like this: select * from tablee where field_serial in ((array[5,6])::int4[]) And Postgresql will complain with the followin

Stream seek error

Hi all! Since Npgsql RC1, we started to receive some error reports about problems when closing connections. The typical stack trace looked like this: System.NotSupportedException : This stream does not support seek operations. at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin) at System.IO.BufferedStream.FlushRead() at System.IO.BufferedStream.WriteByte(Byte value) − at Npgsql.NpgsqlQuery.WriteToStream(Stream outputStream) in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlQuery.cs:line 62 − at Npgsql.NpgsqlReadyState.QueryEnum(NpgsqlConnector context, NpgsqlCommand command) in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlReadyState.cs:line 64 − at Npgsql.NpgsqlConnector.ReleasePlansPortals() in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnector.cs:line 373 − at Npgsql.NpgsqlConnectorPool.UngetPooledConnector(NpgsqlConnection Connection, NpgsqlConnector Connector) in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line 541 − at Npgsql.NpgsqlConnectorPool.ReleasePooledConnector(NpgsqlConn