From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tom Coogan <nocera@gmail.com>
cc: sfrost@snowman.net, pgsql-performance@postgresql.org
Subject: Re: Inefficient filter order in query plan
In-reply-to: 
 <CAN07wv+QNjsZyNj4JWOmkupr9YrdOLcbqCyGAbBxEnofwgN14Q@mail.gmail.com>
References: 
 <CAN07wvLhJhWApx2uGiyeOeCMtXjLw8W84vNNxrhcNvLxKjhTdQ@mail.gmail.com>
 <1633.1393520657@sss.pgh.pa.us>
 <CAN07wv+QNjsZyNj4JWOmkupr9YrdOLcbqCyGAbBxEnofwgN14Q@mail.gmail.com>
Comments: In-reply-to Tom Coogan <nocera@gmail.com>
 message dated "Thu, 27 Feb 2014 15:34:04 -0500"
Date: Thu, 27 Feb 2014 15:47:30 -0500
Message-ID: <15431.1393534050@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Tom Coogan <nocera@gmail.com> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance