AW: [HACKERS] [hackers]development suggestion needed (filepath as symlink) - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: [HACKERS] [hackers]development suggestion needed (filepath as symlink)
Date
Msg-id 219F68D65015D011A8E000006F8590C603FDC210@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List 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.
> > 
> > Andreas
> 
> Is that really a problem on modern operating systems?

Yes, in this regard most OS's (not only Unix) are quite old in their design.
(A . file, that has a sorted list of files and stats)
The problem starts to get severe at about 3000 - 10000 files,
depending on the average filename length.
Change one file --> write whole dirfile.
Depending on the system simple file create or fstat
drops to 3 files per second or worse.

Once the files are in cache, the performance is usually
good again.

But imho 300 ms for a temp file create is way too much.

Maybe we could only put the temp files in a different directory.
They are where performance matters.
If a normal table create takes a few seconds that is not a real problem.

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

You can't have the one directory. It makes no difference whether 
that dir has 5000 symlinks or 5000 files performance wise.

Andreas


pgsql-hackers by date:

Previous
From: Stephen Birch
Date:
Subject: Daily regression testing via vmware - useful?
Next
From: Peter Mount
Date:
Subject: RE: [HACKERS] Status on 7.0