Vladimir Sitnikov

The failures above do not look like spelling-induced ones.

Let me reopen this, as I think the feature will be useful.

There are driver-managed structures (e.g. number of server-prepared statements, number of SQL statement cache misses) that might be interesting to monitor. The tricky question is what do we use for...

Buffer reuse is good, however could you clarify if the application ever reuses the SQL statements?

Type 1: ```java ps = con.prepareStatement("select 42"); ... ps = con.prepareStatement("select 43"); ... ps = con.prepareStatement("select 44"); ... ``` Type 2: ```java ps = con.prepareStatement("select ?"); ps.setInt(1, 42); ... ps...

What I mean is parsing is way faster if you omit the parsing altogether by reusing the statements. Note: unique queries cause DB to parse the statement, produce execution plan,...

> using statement or preparedStatement (or preparedStatement with highly dynamic query which make the cache nearly useless) has little interest in this discussion Let me phrase it in a following...

Regarding the patch itself, I do not like either the naming `ParserState` or the way it is implemented. It turns out `ParserState` is not a state of a parser, but...

>The question is : do you think the idea (parsing optimisation through buffer reuse) is worth pursuing ? I'm afraid there might be multiple questions hiding behind this. a) Frankly...

@MarekUniq , I believe I resolved Resources.with-related issues in https://github.com/pgjdbc/pgjdbc/pull/2573. Are you sure it is still a problem for you?