From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alex Pilosov <alex(at)pilosoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: operators and indices? |
Date: | 2001-05-18 06:26:09 |
Message-ID: | 14094.990167169@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> I've noticed that all custom operators or inet type (such as <<, <<=, etc)
> cannot use an index, even though it is possible to define such an
> operation on an index, for ex:
> X << Y can be translated to "X >= network(Y) && X <= broadcast(Y)" (or so)
You could possibly kluge that in the same way that LIKE is handled,
see match_special_index_operator() and friends. But before we extend
that kluge to too many operators, we ought to think about inventing
a table-driven implementation instead of hardwired code. I have no
idea what one might look like though :-( ... there's not a lot of
regularity visible in the cases at hand.
> According to docs, postgres has hard-coded the ops which match index types
> (such as btree for <,>,=, etc and rtree for @, etc).
It's not hardwired, at least not from the point of view of the mainframe
backend. A given index AM defines the semantics of the operators it can
deal with, and then the pg_amop etc. tables show which operators fill
which roles for each supported datatype.
If you can come up with a useful generalization of that inet property
for other datatypes, we could think about extending the set of operator
roles for btree. But as long as we're dealing with one-of-a-kind
special cases for particular datatypes, I'm not sure there's any better
answer than hardwired code...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2001-05-18 06:26:43 | AW: Adding index flag showing tuple status |
Previous Message | Tom Lane | 2001-05-18 06:07:39 | Re: Plans for solving the VACUUM problem |