From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Hansen <john(at)geeknet(dot)com(dot)au> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] Bug in create operator and/or initdb |
Date: | 2005-01-31 00:00:17 |
Message-ID: | 10322.1107129617@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Hansen <john(at)geeknet(dot)com(dot)au> writes:
>> On the contrary I'm using it for something that isn't really what it was
>> designed for precisely *because* of the index methods. What index access
>> methods are you looking for that are lacking?
>>
>> db=> explain select * from foo where foo_code << '4.0.0.0/8';
> explain select * from foo where foo_code >> '220.244.179.214/32';
Note also that the btree optimization for << depends on having a
plan-time-constant righthand side; so it's useless for joins, for
instance. I didn't look closely, but I'd suppose that rtree could
help for << searches without that constraint.
Looking to the future, it might be better to base this on gist instead
of rtree indexes --- gist is being worked on semi-actively, rtree isn't
really being touched at all.
But the immediate problem is that I don't think we can integrate this
if it doesn't handle IPv6 addresses. We aren't going to want to
backslide on having full IPv6 support.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Hansen | 2005-01-31 00:44:12 | Re: [BUGS] Bug in create operator and/or initdb |
Previous Message | John Hansen | 2005-01-30 23:18:23 | Re: [BUGS] Bug in create operator and/or initdb |