Oliver Jowett <oli...@opencloud.com> writes:

OK, I should not have put this "reminder" above. I thought I would simplify the discussion but it did not.

According to: http://www.postgresql.org/docs/8.1/interactive/sql-prepare.html as well as to any other non-DB specific, similar documentation, the server is able to plan the query at parse time BEFORE receiving any actual parameter. Connection.preparedStatement()'s Javadoc calls this "pre-compilation" (and it's optional).

Hum, interesting. Looks like "lazy prepared" statement, no pre-compilation? If you delay parsing & planning then of course you would not need to go back in time to add late optimizations...

However, what about the following executions of the same and now already prepared and planned statement? Now you would have to go back in time to perform any .setMaxRows() optimization, right?

I assume here that it's the query planning phase that would benefit from any .setMaxRows() optimization, correct me if I'm wrong.

Then you also avoid any latency benefit that _could_ arise thanks to pre-compilation. At least for the first execution.

Sure, but for such high-level architectural questions you can easily understand that I prefer to read your enlightning explanations.