Marc Herbert wrote:
Oliver Jowett <oli...@opencloud.com> writes:
the query is parsed and planned immediately before execution.
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...
I don't know what you mean by "lazy prepared" statements. We give the
statement to the server for parsing and planning at the point when we
know both the query and the parameter types -- which, because of the
JDBC API design, means just before execution. We retain the parse/plan
results on the server side when it looks like the statement will be
reused (using a simple "how many times has this statement already been
reused?" metric), otherwise we reparse/replan on each execution.
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?
It's no different to the case where you change the parameter types really.
-O
24 messages in org.postgresql.pgsql-jdbcRe: Limit vs setMaxRows issue
