From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tom Coogan <nocera(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Inefficient filter order in query plan |
Date: | 2014-02-27 18:24:11 |
Message-ID: | 20140227182411.GR2921@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Tom Coogan <nocera(at)gmail(dot)com> writes:
> > I'd like to understand why PostgreSQL is choosing to filter on the most
> > inefficient predicate first in the query below.
>
> 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.
>
> 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.
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.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-27 19:02:27 | Re: Inefficient filter order in query plan |
Previous Message | Tom Lane | 2014-02-27 17:04:17 | Re: Inefficient filter order in query plan |