On 12/16/05, Kyle Cordes <kyle(at)kylecordes(dot)com> 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
set statement_timeout in postgresql.conf
(DBA: DataBase Aniquilator ;)
In response to
pgsql-performance by date
|Next:||From: Tomasz Rybak||Date: 2005-12-16 14:47:19|
|Subject: Re: Overriding the optimizer|
|Previous:||From: Merlin Moncure||Date: 2005-12-16 14:40:39|
|Subject: Re: How much expensive are row level statistics?|