I read in the release notes for 2018R3 that “PostgreSQLDatabase no longer blocks other threads while executing a prepared statement, assuming the MultiThreaded property is set of course” (#37806). But I also read in help for PostgreSQLDatabase.Multithreaded that “performance is greatly improved if MultiThreaded = False”.
What I want to know is why is performance greatly improved? What’s going on to make Multithreaded slower? And what kind of performance difference is it?
I’m guessing it’s the same issues that relate to Threads in general, i.e., switching contexts is expensive so doing that will degrade performance. When MultiThreaded is FALSE, the plugin will not have to give Xojo time to switch contexts.
Having said that, we have had exactly zero performance issues with Postgres through that plugin.
FB 37806 , stated in the release notes 2018R3, should have been fixed.
The Multithreaded property is True per default, so in my projects it should start working as expected from now on. But…
at some place within a simple thread, running every 5 seconds, I get some data from my PG database using prepared statements. Sometimes it works well, I get all the 5 fields within a recordset as expected, and sometimes I get a recordset containing only 2 or 3 of the five fields the select-query should deliver. This is what the debugger shows me. And of course, when I intend to use the fields not delivered, I get a NilObjectException.
It turns out that explicit setting the Multithreaded of the database object to False, solves the problem, which mean I did not get this exception after doing so and it works again as it used to.
So in my project, fixing 37806 did not solve a problem but created one.
I am curious if some of you guys see the same behavior with the Multithreaded property ON (which is default) Mind that I only had this problem where I requested for data within a thread.