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 either
>all or none of the rows, clearly not the right answer.
>
>
So if the random function was stable, you either get all or none, as et
gets executed only ones ?
>An indexscan is a legal optimization only if the function(s) in the
>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.
>
>
Now 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 ?
Well maybe the real question is how does the executer match an index, or
am I off track ?
/BL
