On Thu, Feb 27, 2014 at 3:47 PM, Tom Lane wrote:
> 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 o
On Thu, Feb 27, 2014 at 12:04 PM, Tom Lane wrote:
>
> It doesn't know that LIKE is any more expensive than the other operators,
> so there's no reason to do them in any particular order.
>
Thanks Tom but why would strict equality checking (e.g. model =
'User') have the same cost as LIKE operation
I'd like to understand why PostgreSQL is choosing to filter on the most
inefficient predicate first in the query below.
Version: PostgreSQL 9.3.2 on x86_64-unknown-linux-gnu, compiled by gcc
(SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773], 64-bit
Hardware: 24 2.93GHz Xeon cores and 32
