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 pl
Andomar writes:
> Below is an example output from log_planner_stats:
> LOG: PLANNER STATISTICS
> DETAIL: ! system usage stats:
> ! 0.000132 elapsed 0.00 user 0.00 system sec
> ! [0.181972 user 0.052991 sys total]
> ! 0/0 [0/248] filesystem bl
On December 21, 2014 04:08:43 PM Andomar wrote:
> It is not always easy to tell the query type (function, prepared or
> ad-hoc.) We use Python in mod_wsgi with psycopg2. The code shows ad-hoc
> SQL, but who knows what the many layers between Python and the database do.
psycopg2 sends the SQL you
Thanks for your reply, I have a follow-up question:
c) Can you monitor the query parser as a whole, with stats like
parses/sec or cache hits/sec?
Possibly log_parser_stats/log_planner_stats/log_statement_stats
would help you. They're pretty old-school though; you'd need to
write some tool that
Andomar writes:
> We run a Postgres 9.1 system that handles a lot of identical queries
> (around 500 per second.) The queries originate from a Python WSGI script
> running under Apache.
> Performance is an issue, and we suspect query planning might be an
> underlying cause. I've rewritten the
Hi,
We run a Postgres 9.1 system that handles a lot of identical queries
(around 500 per second.) The queries originate from a Python WSGI script
running under Apache.
Performance is an issue, and we suspect query planning might be an
underlying cause. I've rewritten the scripts from ad-hoc
