* Tom Lane (tgl@xxxxxxxxxxxxx) wrote: > Tom Coogan <nocera@xxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
