Tom Coogan <nocera@xxxxxxxxx> writes: > Thanks Tom but why would strict equality checking (e.g. model = > 'User') have the same cost as LIKE operations which (may) have to do > pattern matching? A bit of consultation of pg_proc.procost will show you that just about the only internal functions with costs different from 1X cpu_operator_cost are those that do some sort of database access (and, in consequence, have true costs a couple orders of magnitude higher than a simple comparison). We may eventually get around to refining the cost model so that it can tell the difference between = and LIKE, but nobody's yet done the work to decide which functions ought to get assigned what costs. I'm disinclined to single out LIKE for special treatment in the absence of some sort of framework for deciding which functions are worth penalizing. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
