From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Dimitri Fontaine" <dimitri(at)2ndQuadrant(dot)fr>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Range Types, discrete and/or continuous |
Date: | 2010-11-01 19:36:39 |
Message-ID: | m2r5f46dko.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Would you be comfortable writing that '012[3-5]' range as
> '[0123, 0126)' or something similar? What benefits do you see to
> using a range for prefixes versus a regular expression?
Your proposed syntax would do fine, sure. Something like this is even on
the TODO list for prefix indexing, but for the internal representation,
as I think there might be some optimisation potential there. Meanwhile,
it would be easy enough to accept alternative input syntax.
I don't see what benefits I'd get from regexp alike input syntax as all
we need to support is 'foo.*', or if you prefer LIKE syntax, 'foo%'.
Now please remind that the literal is a full phone number, and the table
has the prefixes. So the table would have regular expressions and the
indexing would be about optimising searches of which regexp "best" fits
the input literal. It seems to me the idea of a range makes it easier
here.
Oh, and there's a meaningful overlap notion too, even if depending on
the application you can't enforce non-overlapping ranges (a carrier
might own almost all the '01234' prefix, but another one owns the
'012345' prefix). It gets very funny if you include the country code in
the prefix, too, as they run from one to 5 digits according to
http://en.wikipedia.org/wiki/List_of_country_calling_codes
Still, we're talking about continuous ranges I think, because there's no
way to count the elements that fits in any given prefix_range.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-11-01 20:02:47 | Re: SR fails to send existing WAL file after off-line copy |
Previous Message | Kevin Grittner | 2010-11-01 18:29:49 | Re: revision of todo: NULL for ROW variables |