Claudio Freire <klaussfreire@xxxxxxxxx> writes: > Alternatively, a token startup cost could be added to those kinds of > filtered sequential scans, when the filtering term is selective > enough. That would offset the cost just a little bit, but enough to > favor index over sequential on the right cases. Maybe not so "token". Really, if there's a filter condition having a selectivity of say 1/N, we should expect to have to skip over O(N) tuples before finding a match. (Not sure at this late hour if the expectation is N, or N/2, or something else ... but anyway it's in that ballpark.) We don't take that into account in computing the startup time of a plan node, but I'm thinking we should. In this particular example, that would penalize the seqscan plan and not the indexscan plan, because in the indexscan case the condition is being applied by the index; it's not an after-the-fact filter. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
