On Wed, 2005-05-11 at 22:15 -0400, Bruce Momjian wrote:
The patch was produced quickly to assist tuning efforts during
Scalability Performance benchmarking of PostgreSQL 8.0 carried out at
Unisys Corporation's Mission Viejo engineering laboratory. The
development was sponsored by Unisys
Alvaro Herrera wrote:
Sent: Thursday, May 12, 2005 6:36 AM
To: John Hansen
Cc: Bruce Momjian; Neil Conway; Dennis Bjorklund;
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] lastval()
On Thu, May 12, 2005 at 04:58:54AM +1000, John Hansen wrote:
Alvaro Herrera wrote:
Actually,
Tom Lane [EMAIL PROTECTED] writes:
a_ogawa [EMAIL PROTECTED] writes:
In SQL that executes aggregation, AllocSetReset is called many times and
spend a lot of cycles.
This patch saves the cycles spent by AllocSetReset.
Hmm. It doesn't seem like this could be a big win
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Is that what you had in mind?
Not entirely. We should move around the test sql script and the expected
result file so that the file structure looks exactly like one of the
test-enabled contrib modules.
That's pretty much what I
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not entirely. We should move around the test sql script and the expected
result file so that the file structure looks exactly like one of the
test-enabled contrib modules.
That's pretty much what I thought I did except that I put it
John Hansen [EMAIL PROTECTED] writes:
Hmm, if your app can build any of them at an arbitrary point,
you have a rather serious problem, I'd say. The apps I've
seen build either kind at each call site of such runquery().
Actually, the app that I am referring to, does just that.
However, in
a_ogawa [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Hmm. It doesn't seem like this could be a big win overall. It's not
possible to save a whole lot of cycles inside AllocSetReset, because if
there isn't anything for it to do, it should fall through pretty quickly
anyway.
Patchers,
Here is a small patch to refactor common functionality out of
LockRelease and LockReleaseAll, creating a new static function
RemoveProcLock.
(This comes from Heikki's two-phase commit patch, where it is used more.)
Additionally, I found that no callers of LockReleaseAll and
