"Kevin Grittner" <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> wrote: >> Or is someone prepared to argue that there are no applications out >> there that will be broken if the same query, against the same unchanging >> table, yields different results from one trial to the next? > If geqo kicks in, we're already there, aren't we?
Yup, and that's one of the reasons we have a way to turn geqo off. (geqo is actually a good precedent for this --- notice that it has an on/off switch that's separate from its tuning knobs.) > Isn't an application which counts on the order of result rows > without specifying ORDER BY fundamentally broken? No doubt, but if it's always worked before, people are going to be unhappy anyway. Also, it's not just ordering that's at stake. Try regression=# create table foo as select x from generate_series(1,1000000) x; SELECT regression=# select * from foo limit 10000; x ------- 1 2 3 4 .... regression=# select * from foo limit 10000; x ------- 7233 7234 7235 7236 .... regression=# select * from foo limit 10000; x ------- 14465 14466 14467 14468 .... Now admittedly we've never promised LIMIT without ORDER BY to be well-defined either, but not everybody reads the fine print. This case is particularly nasty because at smaller LIMIT values the result *is* consistent, so you might never notice the problem while testing. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match