Global prepared statements or ? #6
Replies: 3 comments 9 replies
-
|
Functions..? |
Beta Was this translation helpful? Give feedback.
-
|
There seems to be consensus from the server guys that they want to do something about this. The first step would be to determine what we want. |
Beta Was this translation helpful? Give feedback.
-
|
I guess GC could become an issue. And, of course, lookup has to remain fast enough that there's still a gain to be had. What if we had a server-side cache of plans, which the client can opt to use? It would create some room for the server to manage eviction. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
So I started to think about the prepared statement issue and pools.
The JDBC driver creates named prepared statements when it deems that the statement may be re-used enough times.
The problem with this is that it currently doesn't work with pools as statements are per connection. When the connection is returned to the pool we have no guarantee that we get the same connection back when we borrow the connection again.
I've been thinking about how global prepared statements might help here. I'm not clear on how many clients there are. Since the application might have thousands of end users (clients) we don't want to create a prepared statement per user. I'm wondering if creating a unique signature for the statement using MD5 or the like to get a signature for the SQL string and creating the same name for each connection might work?
something like
It would be really nice if we knew in advance what statement names were already created, but either way the worst that would happen here is that we get an error and we can keep going because we know the statement has already been created.
Thoughts ?
Beta Was this translation helpful? Give feedback.
All reactions