Jaime Casanova wrote:
The context is this - in a busy OLTP system, sometimes a query comes
through that, for whatever reason (foolishness on my part as a
developer, unexpected use by a user, imperfection of the optimizer,
etc.), takes a really long time to run, usually because it table-scans
one or more large tables.  If several of these happen at once, it can
grind an important production system effectively to a halt.  I'd like to
have a few users/operations get a "sorry, I couldn't find a good way to
do that" message, rather than all the users find that their system has
effectively stopped working.
... set statement_timeout in postgresql.conf

I found it's better to use "set statement_timeout" in the code, rather than setting it 
globally.  Someone else pointed out to me that setting it in postgresql.conf makes it apply to ALL 
transactions, including VACUUM, ANALYZE and so forth.  I put it in my code just around the queries 
that are "user generated" -- queries that are from users' input.  I expect any SQL that I 
write to finish in a reasonable time ;-).

Craig

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to