On Sun, 2006-12-10 at 18:09 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
