Re: Overriding the optimizer
От | Kyle Cordes |
---|---|
Тема | Re: Overriding the optimizer |
Дата | |
Msg-id | 43A2CCEF.9030605@kylecordes.com обсуждение исходный текст |
Ответ на | Re: Overriding the optimizer (Kevin Brown <kevin@sysexperts.com>) |
Ответы |
Re: Overriding the optimizer
|
Список | 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 по дате отправления: