Re: Inefficient filter order in query plan - Mailing list pgsql-performance

From Tom Lane
Subject Re: Inefficient filter order in query plan
Date
Msg-id 4827.1393527747@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inefficient filter order in query plan  (Stephen Frost <sfrost@snowman.net>)
List pgsql-performance
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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


pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Inefficient filter order in query plan
Next
From: Tom Coogan
Date:
Subject: Re: Inefficient filter order in query plan