From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: fool-toleranced optimizer |
Date: | 2005-03-09 15:44:42 |
Message-ID: | 87sm347rit.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2005-03-09 16:39:31 | Re: One vacuum full is not enough. |
Previous Message | pgsql | 2005-03-09 15:38:27 | Re: [pgsql-hackers-win32] snprintf causes regression |