Re: [HACKERS] [hackers]development suggestion needed (filepath as symlink)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'pgsql-hackers(at)postgreSQL(dot)org '" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as symlink)
Date: 2000-01-19 02:22:38
Message-ID: 200001190222.VAA12708@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > > 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-01-19 02:22:55 Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
Previous Message Bruce Momjian 2000-01-19 02:04:11 Re: [HACKERS] Index recreation in vacuum