| 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: | Whole Thread | Raw Message | 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 |