Re: fool-toleranced optimizer
От | Greg Stark |
---|---|
Тема | Re: fool-toleranced optimizer |
Дата | |
Msg-id | 87sm347rit.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: fool-toleranced optimizer (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
Neil Conway <neilc@samurai.com> writes: > In any case, when this problem does occur, it is obvious to the user that > something is wrong, and no harm is done. I don't see why you say that. The whole complaint here is that it's *not* obvious something is wrong and there *is* damage until it's realized. If I run a query like this on a busy database backing a web site it could easily kill the web site. Or if I start this query and expect it to take an hour then after 2-3 hours when I finally get suspicious I've just wasted 2-3 hours... Or if I add it to the list of nightly jobs I could lose all the other jobs that night that are preempted by this heavy query running for too long. > Given a complex SQL query, it might take a bit of examination to determine > which join clause is missing -- but the proper way to fix that is better > query visualization tools (perhaps similar RH's Visual Explain, for > example). This would solve the general problem: "the user didn't write the > query they intended to write", rather than a very narrow subset ("the user > forgot a join clause and accidentally computed a cartesian product"). I'm unconvinced any tool can make humans infallible. -- greg
В списке pgsql-hackers по дате отправления: