Re: Slow join using network address function
От | Steve Atkins |
---|---|
Тема | Re: Slow join using network address function |
Дата | |
Msg-id | 20040223160734.GA11052@gp.word-to-the-wise.com обсуждение исходный текст |
Ответ на | Slow join using network address function ("Eric Jain" <Eric.Jain@isb-sib.ch>) |
Список | pgsql-performance |
On Mon, Feb 23, 2004 at 12:48:02PM +0100, Eric Jain wrote: > I'm trying to join two tables on an inet column, where one of the > columns may contain a subnet rather than a single host. Somehow the > operation isn't completing quite fast enough, even though neither table > is very large: > > table | rows > --------------------+-------- > clients | 115472 > clients_commercial | 11670 [snip] > Anything else I could try? BTREE indexes don't seem to work with the <<= > operator; is this not possible in principal, or simply something that > has not been implmented yet? I've been looking at a similar problem for a while. I found that the inet type didn't really give me the flexibility I needed, and indexing it in a way that worked with CIDR blocks didn't seem easy (and maybe not possible). So I rolled my own, based on the seg sample. <http://word-to-the-wise.com/ipr.tgz> is a datatype that contains a range of IPv4 addresses, and which has the various operators to make it GIST indexable. Untar it into contrib and make as usual. Input is of the form '10.11.12.13' or '10.11.12.13.0/25' or '10.11.12.13-10.11.12.13.127'. The function display() takes an ipr type and returns it formatted for display (as a dotted-quad if a /32, as CIDR format if possible, as a range of dotted-quads otherwise). A bunch of operators are included, but '&&' returns true if two ipr fields intersect. Bugs include: 0.0.0.0/0 doesn't do what it should on input. No documentation. No cast operators between ipr and inet types. No documentation. I was planning on doing some docs before releasing it, but here it is anyway. Cheers, Steve -- -- Steve Atkins -- steve@blighty.com
В списке pgsql-performance по дате отправления: