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.

You mean with Multithreaded=True?

Sorry, yes, that’s the only way we use it.

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.

I’ll test that today as ALL of our queries are done in threads.

Thanks Kem. Curious what you results will be.

No issues, and we load quite a few columns from each of our tables via our ORM objects and prepared statements.

I have to ask… are you sure you updated the plugin?

It doesn’t give me a version number, but I am sure it’s the one that came with 2018R3 today.

I would have accepted a simple “yes”. :slight_smile:

That’s on a Mac?

I was in the mood of taking screenshots due to other issues … :slight_smile:
I am on Windows .

What version of Postgres?

10.3 on a Linux box

I’m using 10.4, though it’s hard to imagine that would make a difference.

Thing is that I don’t se the issue where database interactions is in the main-tread of my application.
Will try to reproduce in a small project.