perf: cache result set column mapping for prepared statements #614
Conversation
Current coverage is 58.17% (diff: 90.00%)@@ master #614 diff @@
==========================================
Files 148 148
Lines 15616 15630 +14
Methods 0 0
Messages 0 0
Branches 3091 3094 +3
==========================================
+ Hits 9078 9093 +15
Misses 5307 5307
+ Partials 1231 1230 -1
|
This PR tries to fix #607. @vlsi I have a few comments based on your remarks.
The cache itself is in the |
Only a caching getter is required. Setter is not required.
I'm not sure. However, caching resultset fields should be done in In particular
Technically speaking, |
So, the code that creates and initializes the map would be duplicated (a few lines, using a Originally, the cache was supposed to be for I also wonder about |
What if a connection would be such a class? |
I think so |
I think so. |
|
... or rather return null, meaning cache is not supported and the result set has to create a proper map. |
This sounds reasonable. |
If |
It might deserve some benchmarking. Any ideas? |
I think that the optimization is worth for statements that are executed many times, in which case it is going to be named. So as a first implementation, it is probably not worth trying to retain from first call. At least, this is what I am currently doing. We can change later on for more complicated logic if we feel it is necessary. |
@> in which case it is going to be named. The sad thing is lots of users apply "never use server-prepared" mode due to various limitations. So, it would be nice to have that
Covering just "server-prepared" in the first implementation would be fine. |
03ba513
to
ba14509
I am not sure what I did. Re-opening PR. Sorry about that. |
* | ||
* @return null if the query implementation does not support this method. | ||
*/ | ||
HashMap<String, Integer> getResultSetColumnNameIndexMap(); |
vlsi
Aug 3, 2016
Member
Please use interfaces, not specific classes
Please use interfaces, not specific classes
assertNotNull(columnNameIndexMap); | ||
rs.close(); | ||
stmt.close(); | ||
// Prepared statement |
vlsi
Aug 3, 2016
Member
"prepared statement" deserves its own test method.
It is typically better have "27 of 67 failures" than "1 of 1 failure".
With more fine granular tests it might be easier to track the progress & debug.
However, I do not ask to always split each assertion to its own test method.
"prepared statement" deserves its own test method.
It is typically better have "27 of 67 failures" than "1 of 1 failure".
With more fine granular tests it might be easier to track the progress & debug.
However, I do not ask to always split each assertion to its own test method.
columnNameIndexMap = getResultSetColumnNameIndexMap(rs); | ||
assertNotNull(columnNameIndexMap); | ||
rs.close(); | ||
// make sure the statement is named |
vlsi
Aug 3, 2016
Member
This one deserves its own test method as well
This one deserves its own test method as well
Here are benchmark results:
Thus I would suggest caching the Before:
After:
|
For server-prepared statements, Map<ColumnName, ColumnPosition> is reused, thus resultSet.getXXX(String) is faster. Benchmarks show reduced heap allocation, however the response time seems to be not affected. closes pgjdbc#614 closes pgjdbc#607
No description provided.