David, > Luke, would it help to have one machine read the file and > have it connect to postgres on a different machine when doing > the copy? (I'm thinking that the first machine may be able to > do a lot of the parseing and conversion, leaving the second > machine to just worry about doing the writes) Unfortunately not - the parsing / conversion core is in the backend, where it should be IMO because of the need to do the attribute conversion there in the machine-native representation of the attributes (int4, float, etc) in addition to having the backend convert from client encoding (like LATIN1) to the backend encoding (like UNICODE aka UTF8). There are a few areas of discussion about continued performance increases in the codebase for COPY FROM, here are my picks: - More micro-optimization of the parsing and att conversion core - maybe 100% speedup in the parse/convert stage is possible - A user selectable option to bypass transaction logging, similar to Oracle's - A well-defined binary input format, like Oracle's SQL*Loader - this would bypass most parsing / att conversion - A direct-to-table storage loader facility - this would probably be the fastest possible load rate - Luke
