* Tom Lane (t...@sss.pgh.pa.us) wrote: > Tom Coogan <noc...@gmail.com> writes: > > I'd like to understand why PostgreSQL is choosing to filter on the most > > inefficient predicate first in the query below. > > It doesn't know that LIKE is any more expensive than the other operators, > so there's no reason to do them in any particular order. > > You could try increasing the cost attributed to the texticlike() function > if you don't like the results you're getting here.
Perhaps we should be attributing some additional cost to operations
which (are likely to) require de-TOAST'ing a bunch of values? It's not
obvious from the original email, but it's at least my suspicion that the
difference is amplified due to de-TOAST'ing of the values in that text
column, in addition to the straight-up function execution time
differences.
Costing integer (or anything that doesn't require pointer maniuplations)
operations as cheaper than text-based operations also makes sense to me,
even though of course there's more things happening when we do these
comparisons than the simple CPU-level act of doing the cmp.
Thanks,
Stephen
signature.asc
Description: Digital signature
