From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, peter_e(at)gmx(dot)net |
Subject: | Re: PostgreSQL 7.3.3 and Intel C compiler |
Date: | 2003-07-22 06:04:33 |
Message-ID: | 4035.1058853873@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs(at)cybertec(dot)at> writes:
> There is one nifty detail which seems VERY strange to me: If
> serializable mode is set in postgresql.conf the system was 3 times
> faster (~ 7.5 sec. vs. 2.5sec). If serializable mode was set for every
> transaction (using set at the beginning of the transaction) serializable
> mode was as fast as read committed.
Seems pretty strange to me too. I can believe that taking a new
snapshot for each command (as READ COMMITTED mode does) might take a
significant amount of time, especially if you have a large number of
backends connected. (I think the time to get the snapshot data is
linear in the number of live backends; also there is the possibility
of contention on the PROC array when multiple backends need to fetch
snapshots at the same time.) But if that's where the performance
difference is, it wouldn't matter whether you start in serializable
mode by default or issue a SET command to select it.
> I am sorry but I cannot provide you the tools we have used because we
> have a non disclosure agreement with the customer. I will try to verify
> this with my machines and a simple self-made benchmark.
Please try to create a self-contained test case to demonstrate this
behavior. I'd like to try to profile it...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marcus Brger | 2003-07-22 06:19:17 | Re: php with postgres |
Previous Message | Gavin Sherry | 2003-07-22 05:47:40 | Re: PostgreSQL 7.3.3 and Intel C compiler |