On Sun, 2006-12-10 at 18:09 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > The EA case is pretty straightforward though;
>
> Well, no its not, as you'll recall if you re-read the prior discussions.
> The killer problem is that it's unclear whether the early termination of
> the query represents an error condition or not. If it's not an error
> then you've got a serious problem for non-SELECT queries (which EA
> actually executes, remember)
I was expecting to take the non-ERROR route, realising all of the
problems you mention make the issue so costly to solve that way. Most
big queries are SELECTs without any updates and its those we care about
here. Anybody doing huge updates needs other assistance, IMHO.
Intermediate results are always better than none at all. I do understand
what a partial execution would look like - frequently it is the
preparatory stages that slow a query down - costly sorts, underestimated
hash joins etc. Other times it is loop underestimation, which can
usually be seen fairly quickly.
I foresaw that it would be possible to enforce EA as a read-only
transaction, or throw an error (with no output) when issued in
time-limited form. Maybe that isn't possible.
Yes, I am looking for a fix that can be accomplished without major work
and/or change. This topic is a pain, but not such a priority feature.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com