Hate to reply to my own email, but now that I started thinking about
this, there are few more things about network types in catalog that should
be fixed:
a) inet and cidr should be hashable (they are memset'd on input, and the
only way values are equal is for their binary representations to be
equal). All necessary stuff appears to be already in pg_amop.
b) both inet and cidr should be merge-joinable for operator = using
network_lt as sorting function.
I'm also thinking that <<, <<=, etc functions must be using an index, but
I'm still trying to understand the way pg_operator, pg_amop, pg_amproc all
fit together...
On Sat, 9 Jun 2001, Alex Pilosov wrote:
> Hi,
>
> I noticed that postgresql won't ever use a merge join when dealing with
> inet types (for t1.ip=t2.ip, where merge is definitely the best method).
> Delving into pg_operator, it appears that = for inet datatype is not
> created with any left_sort_op/right_sort_op and thus won't merge won't be
> possible. To me, this looks like an oversight, as (at least for inet
> type), network_eq should be able to properly sort the data.
>
> Anyone up to modify the catalog accordingly for 7.2?
>
> (For cidr datatype this doesn't exactly apply, I think, because of all the
> trickery with netmasks, network_eq may not properly sort the cidr data. I
> need to think more about this)
>
>
> Thanks
> -alex
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
