pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedJDBC autocommit versus own commits performance
2+ messages / 2 participants
[nested] [flat]
* JDBC autocommit versus own commits performance
@ 2001-03-13 00:18 David Wall <d.wall@computer.org>
2001-03-13 11:38 ` Re: JDBC autocommit versus own commits performance Gunnar R|nning <gunnar@candleweb.no>
0 siblings, 1 reply; 2+ messages in thread
From: David Wall @ 2001-03-13 00:18 UTC (permalink / raw)
To: pgsql-interfaces
I'm using Postgresql 7.1beta4 with JDBC, and I was wondering if I should go to the trouble of modifying my connection pool to manage two pools, once with setAutoCommit(false) and the other with setAutoCommit(true).
As it is, I turne off auto commit since in my transaction processing, I need to control the commit/rollback.
But, there are also a lot of cases where I'm doing a simple query and I don't need transaction isolation, per se. Is the performance better if I use auto-commit than if I SELECT and do a commit() myself? And is there any benefit to doing a rollback on a select instead of a commit, since nothing changed?
Would there be a benefit with auto commit off if I had to do several different SELECTs, since I'd only have to do one commit at the end instead of the autocommits after each step?
Thanks,
David
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: JDBC autocommit versus own commits performance
2001-03-13 00:18 JDBC autocommit versus own commits performance David Wall <d.wall@computer.org>
@ 2001-03-13 11:38 ` Gunnar R|nning <gunnar@candleweb.no>
0 siblings, 0 replies; 2+ messages in thread
From: Gunnar R|nning @ 2001-03-13 11:38 UTC (permalink / raw)
To: David Wall <d.wall@computer.org>; +Cc: pgsql-interfaces; pgsql-jdbc@postgresql.org
[CC to the jdbc list]
"David Wall" <d.wall@computer.org> writes:
> [1 <text/plain; iso-8859-1 (quoted-printable)>]
> I'm using Postgresql 7.1beta4 with JDBC, and I was wondering if I should go to the trouble of modifying my connection pool to manage two pools, once with setAutoCommit(false) and the other with setAutoCommit(true).
>
> As it is, I turne off auto commit since in my transaction processing, I need to control the commit/rollback.
>
> But, there are also a lot of cases where I'm doing a simple query and I don't need transaction isolation, per se. Is the performance better if I use auto-commit than if I SELECT and do a commit() myself? And is there any benefit to doing a rollback on a select instead of a commit, since nothing changed?
>
> Would there be a benefit with auto commit off if I had to do several different SELECTs, since I'd only have to do one commit at the end instead of the autocommits after each step?
>
I've been wondering the same thing myself, but haven't gotten around to
test performance implications of different configurations. If you do any
testing, it would be nice if you could share your data.
Having two pools implies that you either have to use more backend processes
though(if you don't reduce the size of the pools). This may or may not be
an issue depending on the OS of your backend.
You could of course also just create different checkout methods for the
same underlying pool, but that would be mostly for convenience and not
performance - although it could be OK if your updates are few compared to
your clean queries.
regards,
Gunnar
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2001-03-13 11:38 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-03-13 00:18 JDBC autocommit versus own commits performance David Wall <d.wall@computer.org>
2001-03-13 11:38 ` Gunnar R|nning <gunnar@candleweb.no>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox