] It's got nothing to do with the basics of software engineering or
] computer science. It's got to do with interface definitions and
] APIs.
]
] Where in open(1) does it specify a limit on the number of files
] permissible in a directory? The closest that it comes, that I can
] see is:
[ ... ]
] All of which quite clearly indicate that if one wants to put all
] of ones allocation of blocks or inodes into a single directory,
] then one can, as long as the name and path length limits are
] observed.
"UNIX, in not preventing you from doing stupid things, permits
you to do clever things which other operatings systems do not
permit.".
I maintain that just because you are not administratively
prohibited from doing stupid things, that in no way makes
doing those things less stupid.
] You're welcome to claim a documentation bug, and add the
] appropriate caveat. It seems clear to me that Hans Reiser (and
] Silicon Graphics before him) have taken the more obvious approach,
] of attempting to remove the performance limitation inherent in the
] existing implementation.
The "performance limitation"?
Get your story straight: is there a limitation, or isn't there?
] You can moan about tree-structured vs relational databases, but if
] your problem space doesn't intrinsically map to a tree, then it
] doesn't stop the tree-structring transformation that Terry
] mentioned from being a gratuitious hack to work around a
] performance problem with the existing implementation.
It is not a "performance problem with the existing implementation",
it is "pilot error".
There is _no_ performance problem with "the existing implementation",
if you treat "postgres" as "the existing implementation"; it will do
what you want, quickly and effectively, for millions of record keys.
Why are you treating an FS as if it were a relational database? It
is a tool intended to solve an entirely different problem set.
You are bitching about your hammer not making a good screwdriver.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message