Jon Nelson jnelson+pg...@jamponi.net wrote:
Are there any performance implications (benefits) to executing
queries in a transaction where
SET TRANSACTION READ ONLY;
has been executed?
I don't think it allows much optimization in any current release.
It wouldn't be a bad idea to use it
Jon Nelson jnelson+pg...@jamponi.net writes:
Are there any performance implications (benefits) to executing queries
in a transaction where
SET TRANSACTION READ ONLY;
has been executed?
No.
regards, tom lane
--
Sent via pgsql-performance mailing list
jnelson+pg...@jamponi.net (Jon Nelson) writes:
Are there any performance implications (benefits) to executing queries
in a transaction where
SET TRANSACTION READ ONLY;
has been executed?
Directly? No.
Indirectly, well, a *leetle* bit...
Transactions done READ ONLY do not generate actual
Chris Browne cbbro...@acm.org writes:
jnelson+pg...@jamponi.net (Jon Nelson) writes:
Are there any performance implications (benefits) to executing queries
in a transaction where
SET TRANSACTION READ ONLY;
has been executed?
Directly? No.
Indirectly, well, a *leetle* bit...
afaik, this should be completely neglectable.
starting a transaction implies write access. if there is none, You do not need
to think about transactions, because there are none.
postgres needs to schedule the writing transactions with the reading ones,
anyway.
But I am not that performance
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Nörder-Tuitje wrote:
| We have a database containing PostGIS MAP data, it is accessed
| mainly via JDBC. There are multiple simultaneous read-only
| connections taken from the JBoss connection pooling, and there
| usually are no active writers.
:[EMAIL PROTECTED] Auftrag von Grega Bremec
Gesendet: Dienstag, 20. Dezember 2005 12:41
An: PostgreSQL Performance List
Betreff: Re: [PERFORM] Read only transactions - Commit or Rollback
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Nörder-Tuitje wrote:
| We have a database containing PostGIS
Hi, Marcus,
Nörder-Tuitje wrote:
afaik, this should be completely neglectable.
starting a transaction implies write access. if there is none, You do
not need to think about transactions, because there are none.
Hmm, I always thought that the transaction will be opened at the first
Markus Schaber schrieb:
Hello,
We have a database containing PostGIS MAP data, it is accessed mainly
via JDBC. There are multiple simultaneous read-only connections taken
from the JBoss connection pooling, and there usually are no active
writers. We use connection.setReadOnly(true).
Now my
Markus Schaber writes:
As I said, there usually are no writing transactions on the same database.
Btw, there's another setting that might make a difference:
Having ACID-Level SERIALIZABLE or READ COMMITED?
Well, if nonrepeatable or phantom reads would pose a problem because
of those
On 12/20/05, Nörder-Tuitje, Marcus [EMAIL PROTECTED] wrote:
MVCC blocks reading processes when data is modified.
That is incorrect. The main difference between 2PL and MVCC is that
readers are never blocked under MVCC.
greetings,
Nicolas
--
Nicolas Barbier
Hi, Tom,
Tom Lane wrote:
Some time ago, I had some tests with large bulk insertions, and it
turned out that SERIALIZABLE seemed to be 30% faster, which surprised us.
That surprises me too --- can you provide details on the test case so
other people can reproduce it? AFAIR the only
12 matches
Mail list logo
