> Note that things will go faster if you do your initial data load using > "copy from stdin" for the initial bulk data load. individual inserts in > postgresql are quite costly compared to mysql. It's the transactional > overhead. by grouping them together you can make things much faster. > copy from stdin does all the inserts in one big transaction. You could do "copy from file" as well right? (no performance difference compared to "copy from stdin") I do this all the time. Also - maybe I misunderstand something, but why does PostgreSQL's implementation prohibit it from ignoring insert errors during a copy? If you added a unique constraint to the table before copying, PostgreSQL would generate errors due to the unique constraint violation - so I don't think any additional locking would be required for it to simply say "If there is an error while copying in, ignore it and continue inserting other rows" PostgreSQL's copy command doesn't currently support this, so the temp table followed by a distinct select is the way to go. But I didn't follow all of the talk about it requiring locking the table and being inherently impossible for PostgreSQL to support. I've wanted a similar feature. I select rows into a table on a regular basis. I'd like to be able to overlap old values and have PostgreSQL ignore failed inserts. SQL Server offers a flag that allows you to ignore inserts whose primary key already exists in the table. The only solution in PostgreSQL is to run a query to manually delete the duplicate rows from a temp table before inserting - which takes much more time.