On 12/16/05, Kyle Cordes <kyle@xxxxxxxxxxxxxx> wrote: > Kevin Brown wrote: > > >Craig A. James wrote: > > > > > >>Hints are dangerous, and I consider them a last resort. > >> > >> > > > >If you consider them a last resort, then why do you consider them to > >be a better alternative than a workaround such as turning off > >enable_seqscan, when all the other tradeoffs are considered? > > > > > > I would like a bit finer degree of control on this - I'd like to be able > to tell PG that for my needs, it is never OK to scan an entire table of > more than N rows. I'd typically set N to 1,000,000 or so. What I would > really like is for my DBMS to give me a little more pushback - I'd like > to ask it to run a query, and have it either find a "good" way to run > the query, or politely refuse to run it at all. > > Yes, I know that is an unusual request :-) > > 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. > > Kyle Cordes > www.kylecordes.com > > set statement_timeout in postgresql.conf -- Atentamente, Jaime Casanova (DBA: DataBase Aniquilator ;)
