From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tom Coogan <nocera@gmail.com>
Cc: sfrost@snowman.net
Cc: pgsql-performance@postgresql.org
Subject: Re: Inefficient filter order in query plan
Date: Thu, 27 Feb 2014 15:47:30 -0500
Message-ID: <15431.1393534050@sss.pgh.pa.us> (raw)
In-Reply-To: <CAN07wv+QNjsZyNj4JWOmkupr9YrdOLcbqCyGAbBxEnofwgN14Q@mail.gmail.com>
References: <CAN07wvLhJhWApx2uGiyeOeCMtXjLw8W84vNNxrhcNvLxKjhTdQ@mail.gmail.com>
<1633.1393520657@sss.pgh.pa.us>
<CAN07wv+QNjsZyNj4JWOmkupr9YrdOLcbqCyGAbBxEnofwgN14Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, nocera@gmail.com, sfrost@snowman.net
Subject: Re: Inefficient filter order in query plan
In-Reply-To: <15431.1393534050@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox