Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Vadim Mikheev <vadim(at)krs(dot)ru>, Lincoln Yeoh <lylyeoh(at)mecomb(dot)com>, pgsql-general(at)postgreSQL(dot)org, PostgreSQL Developers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?
Date: 1999-10-22 15:08:01
Message-ID: 20506.940604881@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> But what makes me unhappy right now is that with -F COPY FROM takes
>> JUST 3 min !!! (And 16 min without -F)
>> Isn't parsing/planning overhead toooo big ?!

> Yikes. I always thought it would be nice to try and cache query plans
> by comparing parse trees, and if they match cached versions, replace any
> constants with new ones and use cached query plan. Hard to do right,
> though.

But INSERT ... VALUES(...) has such a trivial plan that it's hardly
likely to be worth caching. We probably ought to do some profiling to
see where the time is going, and see if we can't speed things up for
this simple case.

In the meantime, the conventional wisdom is still that you should use
COPY, if possible, for bulk data loading. (If you need default values
inserted in some columns then this won't do...)

regards, tom lane

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bob Kline 1999-10-22 15:26:40 Re: [GENERAL] CREATE VIEW blah AS SELECT DISTINCT etc
Previous Message Moray McConnachie 1999-10-22 13:54:34 Re: [GENERAL] CREATE VIEW blah AS SELECT DISTINCT etc

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-10-22 15:15:41 Re: [HACKERS] Planning final assault on query length limits
Previous Message Tom Lane 1999-10-22 14:48:51 Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1