Re: Overriding the optimizer - Mailing list pgsql-performance

From Kyle Cordes
Subject Re: Overriding the optimizer
Date
Msg-id 43A2CCEF.9030605@kylecordes.com
Whole thread Raw
In response to Re: Overriding the optimizer  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: Overriding the optimizer
List pgsql-performance
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



pgsql-performance by date:

Previous
From: Moritz Bayer
Date:
Subject: Re: Crashing DB or Server?
Next
From: "PostgreSQL"
Date:
Subject: ALTER TABLE SET TABLESPACE and pg_toast