Обсуждение: Re: [HACKERS] [hackers]development suggestion needed (filepath as symlink)

> Yes, that's about the sum of it.  Why not the links?  I think 
> that it's an elegant way of designing the whole thing.

The only problem with symlinks is, that it does not solve the 
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.

Andreas

> > Yes, that's about the sum of it.  Why not the links?  I think 
> > that it's an elegant way of designing the whole thing.
> 
> The only problem with symlinks is, that it does not solve the 
> "too many files in one directory to give optimal performance"
> problem for those that have tons of tables.
> 
> Andreas

Is that really a problem on modern operating systems?  We could actually
hash the file names into directory buckets and access them that way, and
have one directory that old symlinks to the hashed files.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

On Tue, 18 Jan 2000, Bruce Momjian wrote:

> > > Yes, that's about the sum of it.  Why not the links?  I think 
> > > that it's an elegant way of designing the whole thing.
> > 
> > The only problem with symlinks is, that it does not solve the 
> > "too many files in one directory to give optimal performance"
> > problem for those that have tons of tables.
> > 
> > Andreas
> 
> Is that really a problem on modern operating systems?  We could actually
> hash the file names into directory buckets and access them that way, and
> have one directory that old symlinks to the hashed files.

Personally, except in *exceptional* circumstances, I hate symlinks...that
was one of my first projects whenI started working at th eocal University,
was to get rid of the garbage "revision control" system they had for
packages installed on the system ...

IMHO, there have been several methods of doing this, some easier then
others, wihtout having to use symlinks for them ... can we *please* avoid
using them?


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> > > Yes, that's about the sum of it.  Why not the links?  I think
> > > that it's an elegant way of designing the whole thing.
> > The only problem with symlinks is, that it does not solve the
> > "too many files in one directory to give optimal performance"
> > problem for those that have tons of tables.
> Is that really a problem on modern operating systems?  We could actually
> hash the file names into directory buckets and access them that way, and
> have one directory that old symlinks to the hashed files.

imho symlinks is exactly the wrong way to head on this. If the system
needs to know the true location of something, then it may as well
refer to that location explicitly. Our storage manager should learn
how to deal with explicit locations, and we shouldn't implement this
just as a patch on the table creation code.

My $.02...
                  - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> > > > Yes, that's about the sum of it.  Why not the links?  I think
> > > > that it's an elegant way of designing the whole thing.
> > > The only problem with symlinks is, that it does not solve the
> > > "too many files in one directory to give optimal performance"
> > > problem for those that have tons of tables.
> > Is that really a problem on modern operating systems?  We could actually
> > hash the file names into directory buckets and access them that way, and
> > have one directory that old symlinks to the hashed files.
> 
> imho symlinks is exactly the wrong way to head on this. If the system
> needs to know the true location of something, then it may as well
> refer to that location explicitly. Our storage manager should learn
> how to deal with explicit locations, and we shouldn't implement this
> just as a patch on the table creation code.
> 

OK, no symlinks.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

At 02:26 AM 1/19/00 +0000, Thomas Lockhart wrote:

>imho symlinks is exactly the wrong way to head on this. If the system
>needs to know the true location of something, then it may as well
>refer to that location explicitly. Our storage manager should learn
>how to deal with explicit locations, and we shouldn't implement this
>just as a patch on the table creation code.

That's my feeling too.

We could document the query needed to list where all tables
are located, grouped by tablespace.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.