Robert Treat <[EMAIL PROTECTED]> writes:
> I thought I saw something this weekend about a new zic/timezone database
> being
> released though having trouble finding out the details now... is this
> something that should be backpatched into the 8.0.x series?
Too late for 8.0.1. It's not like th
On Sunday 30 January 2005 17:01, you wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Any last minute show stoppers that needs a bit more time, let me know
> > before 23:00 GMT
>
> AFAIK we're good to go. I've updated all the version files and release
> notes --- it's ready to tag and w
> 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.
Indeed it can... tho rtree seems to be unable
John Hansen <[EMAIL PROTECTED]> 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
> 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 f
"John Hansen" <[EMAIL PROTECTED]> writes:
> I wouldn't think so, anyone I've spoken with has come up with other ways of
> managing that kind of info, because of, as you mentioned, it's lack of
> proper index methods.
On the contrary I'm using it for something that isn't really what it was
design
"John Hansen" <[EMAIL PROTECTED]> writes:
> Attached, an rtree implementation for inet/cidr values.
Er ... what about IPv6?
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Any last minute show stoppers that needs a bit more time, let me know
> before 23:00 GMT
AFAIK we're good to go. I've updated all the version files and release
notes --- it's ready to tag and wrap.
regards, tom lane
-
On Sat, 29 Jan 2005 18:46:44 +, Mike Rylander <[EMAIL PROTECTED]> wrote :
> For on-disk bitmap indexes, yes. I don't see any reason this couldn't
> be done with GiST, perhaps even as a generalization of the index stuff
> in the int_array contrib module.
I was thinking about playing with th
Any last minute show stoppers that needs a bit more time, let me know
before 23:00 GMT
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)-
Hi,
Attached, an rtree implementation for inet/cidr values.
It's beyond me to implement this as a patch, but if anyone has the time and
energy to do so, feel free!
Comments, positive and negative welcome - and appreciated :)
Kind Regards,
John Hansen
Makefile
Description: Makefile
rtree_
> I suspect that the right thing to do is to kill the inet type
> entirely, and replace it with a special case of cidr. (And
> possibly then to kill cidr and replace it with something that
> can be indexed more effectively.)
Yes, which is actually what brought this to my attention.
I'll be send
Greetings,
I would like to submit my changes to src/port/snprintf.c to
enable %n$ format placeholder replacement in snprintf() and
vsnprintf(). Additionally I implemented a trivial printf().
I also attach a diff for configure.in to include snprintf.o
in pgport but I am sure it is not the right thi
On Sat, Jan 29, 2005 at 01:56:12PM +0200, Victor Y. Yegorov wrote:
> 2) Queries, like "where A = 1" or "where A != 2" will require only 1 scan of
> the index, while "where A < 3" will require 2 stages: 1st create a
> list of
> values lesser then 3, 2nd --- do OR of all bitmaps for that values.
14 matches
Mail list logo
