Tom Lane wrote:
It has nothing to do with speed, it has to do with giving the correct answer. We define "correct answer" as being the result you would get from a naive interpretation of the SQL semantics --- that is, for every row in the FROM table, actually execute the WHERE clause, and return the rows where it produces TRUE.
As an example, a query like
SELECT * FROM mytable WHERE random() < 0.1;
should produce a random sampling of about one-tenth of the rows in mytable.
Nice explaination ...
If we evaluated random() only once in this query, we would get eitherSo if the random function was stable, you either get all or none, as et gets executed only ones ?
all or none of the rows, clearly not the right answer.
An indexscan is a legal optimization only if the function(s) in theNow this sounds like a blink of the problem that I don't understand :-) When you say it evaluate "right side" ones, what kind of information are you (the executer) then getting, and how is the index match then performed. Is all the where clause expression marked as volatile at this level, just to be sure ?
WHERE clause are all STABLE or better. This is because the index access
code will only evaluate the righthand side of the "indexcol = something"
clause once, and then will use that value to descend the btree and
select matching index entries. We must be certain that this gives the
same result we would get from a seqscan.
Well maybe the real question is how does the executer match an index, or am I off track ?
/BL
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
