Re: Bulkloading using COPY - ignore duplicates?

Lee Kindness <lkindness@csl.co.uk>

From: Lee Kindness <lkindness@csl.co.uk>
To: Hannu Krosing <hannu@tm.ee>
Cc: Lee Kindness <lkindness@csl.co.uk>, Patrick Welche <prlw1@newn.cam.ac.uk>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2001-12-13T14:56:52Z
Lists: pgsql-hackers
Hannu Krosing writes:
 > Lee Kindness wrote:
 > > The majority of database systems out there handle this situation in
 > > one manner or another (MySQL ignores or replaces; Ingres ignores;
 > > Oracle ignores or logs; others...). Indeed PostgreSQL currently checks
 > > for duplicates in the COPY code but throws an elog(ERROR) rather than
 > > ignoring the row, or passing the error back up the call chain.
 > I guess postgresql will be able to do it once savepoints get
 > implemented.

This is encouraging to hear. I can see how this would make the code
changes relatively minimal and more manageable - the changes to the
current code are simply over my head!

Are savepoints relatively high up on the TODO list, once 7.2 is out the
door?

 > > My use of PostgreSQL is very time critical, and sadly this issue alone
 > > may force an evaluation of Oracle's performance in this respect!
 > Can't you clean the duplicates _outside_ postgresql, say
 > cat dumpfile | sort | uniq | psql db -c 'copy mytable from stdin'

This is certainly a possibility, however it's just really moving the
processing elsewhere. The combined time is still around the same.

I've/we've done a lot of investigation with approaches like this and
also with techniques assuming the locality of the duplicates (which is
a no-goer). None improve the situation.

I'm not going to compare the time of just using INSERTs rather than
COPY...

Thanks for your response, Lee Kindness.

-- 
 Lee Kindness, Senior Software Engineer, Concept Systems Limited.
 http://services.csl.co.uk/ http://www.csl.co.uk/ +44 131 5575595