Simon Riggs <si...@2ndquadrant.com> writes: > On Wed, 2009-02-04 at 10:55 +0000, Greg Stark wrote: >> Is this basically the same as our current algorithm but without >> multiplexing the tapes onto single files? I have been wondering >> whether we multiplex the tapes any better than filesystems can lay out >> separate files actually. > > I don't think you'll be able to do that more efficiently than we already > do. Read the top of tuplesort.c
Huh? The question I posed was whether we do it any better than filesystems do, not whether we could do a better job. If filesystems can do as good a job then we might as well create separate files for each tape and let the filesystem decide where to allocate space. That would mean we could massively simplify logtape.c and just create a separate file for every tape. Possible reasons that filesystems could do better than us are that they have access to more information about actual storage layout on disk, that they have more information about hardware characteristics, and that it would give the filesystem cache a better idea of the access pattern which logtape.c might be confusing the picture of currently. On the other hand possible reasons why filesystems would suck at this include creating and deleting new files being a slow or locking operation on many filesystems, and dealing with directories of large numbers of files being poorly optimized on others. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
