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