Re: Monitoring query plan cache

> 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