You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently always retrieve SQL counts on execute in the GDS layer, instead we should only retrieve it when JDBC requires it (ie: when using executeUpdate, or with an explicit call of getUpdateCounts).
In earlier versions this made sense because we pipelined the count request immediately after the execute, but since adding cancellation support we had to split that again into separate request/response pairs. Only explicitly requesting this when needed may have a small performance benefit.
Current code already obtains update count if it wasn't retrieved previously, so I deleted the low-level getSqlCounts immediately after execute and after fetching all rows.
This should restore the behavior as it was in Jaybird 2.2, and result in a minor performance improvement when processing result sets, but never obtaining update counts, or when using execute() instead of executeUpdate() (eg when not interested in update counts).
As part of this I also fixed in bug with `getMoreResults()` that did not correctly handle closing of a result set (or server side cursor) if the result set had never been obtained from the statement (eg when using execute, but not calling getResultSet).
Submitted by: @mrotteveel
We currently always retrieve SQL counts on execute in the GDS layer, instead we should only retrieve it when JDBC requires it (ie: when using executeUpdate, or with an explicit call of getUpdateCounts).
In earlier versions this made sense because we pipelined the count request immediately after the execute, but since adding cancellation support we had to split that again into separate request/response pairs. Only explicitly requesting this when needed may have a small performance benefit.
Commits: 1204a26 c56795a
The text was updated successfully, but these errors were encountered: