From: | maumau307 at gmail(dot)com (MauMau) |
---|---|
To: | |
Subject: | [Pljava-dev] Is it safe to use multi-threaded PL/Java in single-threaded postgres process? |
Date: | 2014-04-13 11:16:34 |
Message-ID: | 5F50DAFCABA4426FA54E9D8D0B78B38B@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
Hello all,
it seems most likely that I will fail to convince my colleagues to use
PL/Java. The performance was not as good as I expected compared to running
Java functions in a process different from postgres. On RHEL6 with
PostgreSQL 9.2.8, I got the following results when I ran 10000 UPDATE
statements in a single transaction, excluding the time of BEGIN and COMMIT:
* PL/pgSQL: 20 seconds
* PL/Java: 22 seconds (see the attached BatchPL.java for processing)
* Standalone client running on the same server as the database server: 23
seconds (see Batch.java, which does the same job as BatchPL.java)
I avoided the influence of I/O by setting:
wal_buffers = 16MB
checkpoint_segments = 100
checkpoint_timeout = 1h
So I couldn't insist that PL/Java is required to greatly reduce the overhead
of interprocess communication and process context switches. Any ideas?
Regards
MauMau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Batch.java
Type: application/octet-stream
Size: 1237 bytes
Desc: not available
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20140413/61dea8a8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BatchPL.java
Type: application/octet-stream
Size: 1204 bytes
Desc: not available
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20140413/61dea8a8/attachment-0003.obj>
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2014-04-13 14:47:54 | [Pljava-dev] Is it safe to use multi-threaded PL/Java in single-threaded postgres process? |
Previous Message | Hal Hildebrand | 2014-03-21 15:06:40 | [Pljava-dev] An attempt was made to call a PostgreSQL backend function after an elog(ERROR) had been issued |