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
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 |