> >
> > We did it with C++ and a memory mapped file for persistence.
> > We had to use a 64bit cpu and 12G of RAM.
>
> Wow! That's only 300 bytes of RAM for every 10 digit phone number!
We didn't use all of that, last time I checked it was using apx 4G of
RAM,
We had to plan for every possible U
> Rick Gigger wrote:
>
> I was glad to see this topic come up on the list as I was
> about to start asking about some of these issues myself. I
> would like to discuss each of the methods I have researched
> so far for doing trees in sql and see if anyone has some
> experience or insite into
I was glad to see this topic come up on the list as I was about to start
asking about some of these issues myself. I would like to discuss each of
the methods I have researched so far for doing trees in sql and see if
anyone has some experience or insite into the topic that could help me.
That be
> Christian Fowler wrote:
>
> So it seems Materialized Path is my only option, however I am
> concerned about LIKE performance for the right hand side of
> the tree, where the path is 8digits x 6 levels = 48 chars.
> Should I be concerned? I need split-second real-time
> performance, and can't
Alvar Freude wrote:
I want to change this to bytea to avoid base255 encoding and the character
set problems, but there are still some Bugs with bytea and the like
operator. :-(
Be patient, I'm working on it. Apparently you are the first person to
ever really try to *use* the like operator for byt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
- -- "Joe \"Nuke Me Xemu\" Foster" <[EMAIL PROTECTED]> wrote:
> Here's an alternative which may not perform very well but may
> still be better than risking a full table-scan...
I use exactly this method in a forum software, and it performs VERY
