On 3/13/07, femski <[EMAIL PROTECTED]> wrote:
I have a batch application that writes approx. 4 million rows into a narrow
table. I am using JDBC addBatch/ExecuteBatch with auto commit turned off.
Batch size is 100. So far I am seeing Postgres take roughly five times the
time it takes to do this i
Carlos Moreno wrote:
> Joshua D. Drake wrote:
>
>> insert into foo(bar) values (bang) (bong) (bing) ...?
>>
>>
>>
>
> Nit pick (with a "correct me if I'm wrong" disclaimer :-)) :
>
> Wouldn't that be (bang), (bong), (bing) ??
Yes.
J
>
> Carlos
> --
>
>
> ---
Joshua D. Drake wrote:
insert into foo(bar) values (bang) (bong) (bing) ...?
Nit pick (with a "correct me if I'm wrong" disclaimer :-)) :
Wouldn't that be (bang), (bong), (bing) ??
Carlos
--
---(end of broadcast)---
TIP 2: Don't '
femski wrote:
> Folks !
>
> I have a batch application that writes approx. 4 million rows into a narrow
> table. I am using JDBC addBatch/ExecuteBatch with auto commit turned off.
> Batch size is 100. So far I am seeing Postgres take roughly five times the
> time it takes to do this in the Oracle.
On 3/16/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
Be careful...you are just testing one very specific thing and it its
extremely possible that the Oracle JDBC batch insert is more optimized
than PostgreSQL's. On my little pentium 4 workstation, by inserting
10 rows per insert:
insert values
On 3/16/07, Bob Dusek <[EMAIL PROTECTED]> wrote:
This may or may not be related to what you're seeing... but, when we
changed from Postgres 7.4.2 to 7.4.8, our batch processing slowed down
fairly significantly.
Here's what we were doing:
Step 1) Build a larg file full of SQL insert statements.
On 3/15/07, femski <[EMAIL PROTECTED]> wrote:
I tried maxpages = 0 and full_page_writes=off and it seemed to be taking
forever.
All other tricks I have already tried.
At this point I wondering if its a jdbc client side issue - I am using the
latest 8.1.
(as I said in an earlier post - I am usi
femski <[EMAIL PROTECTED]> writes:
> If 17k record/sec is right around expected then I must say I am little
> disappointed from the "most advanced open source database".
Well, the software is certainly capable of much more than that;
for instance, on a not-too-new Dell x86_64 machine:
regression=
I tried maxpages = 0 and full_page_writes=off and it seemed to be taking
forever.
All other tricks I have already tried.
At this point I wondering if its a jdbc client side issue - I am using the
latest 8.1.
(as I said in an earlier post - I am using addBatch with batch size of 100).
But just in
On 3/15/07, femski <[EMAIL PROTECTED]> wrote:
I am using Oracle XE so its using only one core and doing just fine.
How do I split backend to 4+ processes ?
I don't want to write a multithreaded loader app.
And I didn't think Postgres can utilize multiple cores for the
same insert statement.
we
I am using Oracle XE so its using only one core and doing just fine.
How do I split backend to 4+ processes ?
I don't want to write a multithreaded loader app.
And I didn't think Postgres can utilize multiple cores for the
same insert statement.
thanks,
-Sanjay
On 3/14/07, femski <[EMAIL PROT
On 3/14/07, femski <[EMAIL PROTECTED]> wrote:
Ok, I turned off XDMCP and network bandwidth utilization dropped to less than
5%.
Timings remained the same.
Curiously five times faster time for Oracle came from a client running on a
different host than the server.
To make things worse for Postgre
Ok, I turned off XDMCP and network bandwidth utilization dropped to less than
5%.
Timings remained the same.
Curiously five times faster time for Oracle came from a client running on a
different host than the server.
To make things worse for Postgres, when I replace "hostname" in jdbc string
to "
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> OP said he's using addBatch/executeBatch with a batch size of 100. The
> JDBC driver sends the whole batch before waiting for responses.
Perhaps a bit of checking with a packet sniffer would be warranted.
If it's really working like that he shouldn
Tom Lane wrote:
It sounds like you're incurring a network round trip for each row, which
will be expensive even for a co-located application. Perhaps Oracle's
JDBC driver is smart enough to avoid that. I'm not sure what tricks are
available for bulk loading with our JDBC driver --- the page Hei
femski <[EMAIL PROTECTED]> writes:
> I am runing Postgres 8.2 on OpenSuse 10.2 with latest jdbc driver. I moved
> the app to be collocated with the server. Oracle takes 60 sec. Postgres 275
> sec. For 4.7 million rows.
> There are 4 CPUs on the server and one is runing close to 100% during
> inser
I am runing Postgres 8.2 on OpenSuse 10.2 with latest jdbc driver. I moved
the app to be collocated with the server. Oracle takes 60 sec. Postgres 275
sec. For 4.7 million rows.
There are 4 CPUs on the server and one is runing close to 100% during
inserts.
Network history shows spikes of upto 60%
On 3/13/07, femski <[EMAIL PROTECTED]> wrote:
Folks !
I have a batch application that writes approx. 4 million rows into a narrow
table. I am using JDBC addBatch/ExecuteBatch with auto commit turned off.
Batch size is 100. So far I am seeing Postgres take roughly five times the
time it takes to
femski wrote:
I have a batch application that writes approx. 4 million rows into a narrow
table. I am using JDBC addBatch/ExecuteBatch with auto commit turned off.
Batch size is 100. So far I am seeing Postgres take roughly five times the
time it takes to do this in the Oracle.
The usual trick
19 matches
Mail list logo
