Thanks for the fast reply and explanation, Tom. Overall, I have been pleasantly surprised with the leniency of indexes on range types.
On Sat, May 20, 2017 at 5:00 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Zac Goldstein <goldzz@xxxxxxxxx> writes:
> This uses the index:
> ...
> But this doesn't:
> EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM shot
> WHERE lower(shot.matchsecond) <@ ((shot.matchsecond).match_id,
> numrange(5, 10))::matchsecond_type;
Well, yeah. After inlining the SQL functions, what you have is
> Filter: ((((matchsecond).match_id)::integer = and neither half of the AND has the form "indexed_value indexable_operator
> ((matchsecond).match_id)::integer) AND
> ((numrange(lower(((matchsecond).second):: numrange),
> lower(((matchsecond).second)::numrange), '[]'::text))::numrange <@
> ('[5,10)'::numrange)::numrange))
constant", which is the basic requirement for an index condition. We're a
little bit permissive about what "constant" means, but that most certainly
doesn't extend to expressions involving columns of the table. So the
first clause loses because it's got variables on both sides, and the
second loses because the LHS _expression_ is not what the index is on.
You could build an additional index on that _expression_, if this shape
of query is important enough to you to justify maintaining another index.
regards, tom lane
