Andomar <andomar@xxxxxxxx> writes: > Below is an example output from log_planner_stats: > LOG: PLANNER STATISTICS > DETAIL: ! system usage stats: > ! 0.000132 elapsed 0.000000 user 0.000000 system sec > ! [0.181972 user 0.052991 sys total] > ! 0/0 [0/248] filesystem blocks in/out > ! 0/0 [0/2705] page faults/reclaims, 0 [0] swaps > ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent > ! 0/0 [1/4249] voluntary/involuntary context switches > How can we tell from this whether the query planner used a cached plan? 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. > The logging doesn't look like a cached plan, you can see the 123 value > but not a parameter like $1. This suggests Postgres was previously > compiling around 200 queries a second on our production machine. Is that > even possible? 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. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
