Re: [BUGS] Bug in create operator and/or initdb

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

In response to

Responses

Browse pgsql-hackers by date

  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