Chris Browne 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...
> Transactions don
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
Jon Nelson 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 (pgsql-performance@postgresql.org)
To
Jon Nelson 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 where appropriate, thoug
Are there any performance implications (benefits) to executing queries
in a transaction where
SET TRANSACTION READ ONLY;
has been executed?
--
Jon
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> That surprises me too --- can you provide details on the test case so
>> other people can reproduce it? AFAIR the only performance difference
>> between SERIALIZABLE and READ COMMITTED is the frequency with which
>> t
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 per
Tom Lane <[EMAIL PROTECTED]> writes:
> That surprises me too --- can you provide details on the test case so
> other people can reproduce it? AFAIR the only performance difference
> between SERIALIZABLE and READ COMMITTED is the frequency with which
> transaction status snapshots are taken; your
Markus Schaber <[EMAIL PROTECTED]> writes:
> 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 th
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
http://www.gnu.org/philosophy/no-w
Hello, Andreas,
Andreas Seltenreich wrote:
>>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 occasional writes, you wouldn't be considering autocommi
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 occ
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 ques
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
statem
ailto:[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 co
-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 writer
profession anyway ;-)
regards,
Marcus
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Auftrag von Markus
Schaber
Gesendet: Dienstag, 20. Dezember 2005 11:41
An: PostgreSQL Performance List
Betreff: [PERFORM] Read only transactions - Commit or Rollback
Hello,
We
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 question is what is best perfo
18 matches
Mail list logo
