psycopg2 sends the SQL you feed it straight to the DB. If you don't feed it a
PREPARE statement [1] it'll be an ad-hoc query; the value placeholders will be
interpolated prior to statement submission by psycopg2.
Thanks, that confirms what I saw during tests.
If you're seeing that output then planning happened. The only way you get
a cached plan for a client-issued SQL statement is if the client uses
PREPARE/EXECUTE or the "extended query" protocol (parse/bind/execute).
Neither of those cases would go through here.
So if there was a cached plan, there is no "LOG: PLANNER STATISTICS".
That is helpful, thanks.
Well, at 132 microseconds apiece, it does not seem from this example that
repeat planning is a huge problem for you ... of course, some of your
statements might take longer, but you've not demonstrated here that you
have anything to worry about.
Well that was just an example query, but checking a realistic query on a
test machine shows 15ms spent on query analysis. For 200 queries/sec
that would keep around 3 CPU's busy, which is what we saw. I will try to
verify that using the log_planner_stats option.
Cheers,
Andomar
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
