From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4079: libpq.dll very slow (unusable) |
Date: | 2008-04-03 09:13:04 |
Message-ID: | 171232314.20080403121304@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello, Tom.
Thank a lot Tom.
Just curious, what was the reason?
Regards
You wrote:
TL> "Pavel Golub" <pavel(at)microolap(dot)com> writes:
>> Comparing 8.3.1 to 8.2.5 release INSERT of >1000 rows is very slow.
>> INSERT INTO numbers (numberint, numberstr) VALUES (1, 'One');
>> INSERT INTO numbers (numberint, numberstr) VALUES (2, 'Two');
>> INSERT INTO numbers (numberint, numberstr) VALUES (3, 'Three');
>> ...
>> INSERT INTO numbers (numberint, numberstr) VALUES (1000, 'One thousand');
TL> Fixed for 8.3.2. In the meantime, you might consider modifying your
TL> application to do this as a single insert instead:
TL> INSERT INTO numbers (numberint, numberstr) VALUES
TL> (1, 'One'),
TL> (2, 'Two'),
TL> (3, 'Three'),
TL> ...
TL> (1000, 'One thousand')
TL> A quick test says that this way is between three and four times faster,
TL> even without considering the impact of the problem you're complaining
TL> about.
TL> regards, tom lane
--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | jitendra | 2008-04-03 10:15:02 | BUG #4087: table creation problem using python |
Previous Message | Tom Lane | 2008-04-02 23:15:56 | Re: BUG #4085: No implicit cast after coalesce |