Re: Inefficient filter order in query plan

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> 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.

Could be. We've discussed adding some charge for touching
likely-to-be-toasted columns in the past, but nobody's done anything
about it. Note that I'd rather see that implemented as a nonzero cost
for Vars than as a charge for functions per se.

> 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.

Right. We've bumped up the cost numbers for some extremely expensive
functions, but I would like to have some actual data rather than just seat
of the pants guesses before we go fooling with the standard CPU cost
estimates for things at the level of regex matches.

regards, tom lane