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

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
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:26:43
Message-ID: 388520E3.D192ED7B@alumni.caltech.edu
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.

My $.02...

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-01-19 02:27:25 Re: [HACKERS] [hackers]development suggestion needed (filepath as symlink)
Previous Message Hiroshi Inoue 2000-01-19 02:23:55 RE: [HACKERS] Index recreation in vacuum