log_min_cost_statement

[Nichlas Löfdahl]

Hello!

Would it be possible to have an option "log_min_cost_statement", similar to
"log_min_duration_statement" except that it logs all statement that has
an minimum cost estimated by the planner? I think it would be easier to
find unoptimized queries that way.

Just a thought!

/Nichlas

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Post by Nichlas Löfdahl
Would it be possible to have an option "log_min_cost_statement", similar to
"log_min_duration_statement" except that it logs all statement that has
an minimum cost estimated by the planner? I think it would be easier to
find unoptimized queries that way.

Why would you want to filter on the planner's cost estimate rather than
the true runtime?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Bruce Momjian]

Post by Nichlas Löfdahl
Hello!
Would it be possible to have an option "log_min_cost_statement", similar to
"log_min_duration_statement" except that it logs all statement that has
an minimum cost estimated by the planner? I think it would be easier to
find unoptimized queries that way.

Uh, yea, I guess we could, but the costs are more comparison with other
costs, not really with other queries, I think, so I am not sure it would
be meaningful.

[Peter Eisentraut]

Post by Nichlas Löfdahl
Would it be possible to have an option "log_min_cost_statement",
similar to "log_min_duration_statement" except that it logs all
statement that has an minimum cost estimated by the planner? I think
it would be easier to find unoptimized queries that way.

If you believe that the costs have any absolute meaning at all then they
should be proportional to the execution time, so the existing setting
should be enough.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly