Re: Inefficient filter order in query plan

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Tom Coogan <nocera@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