Jan Wieck <[EMAIL PROTECTED]> writes:
>> That's irrelevant to the problem, though. Unless the ARC code uses data
>> structures that are more amenable to localized locking than the old
>> global buffer freelist. (Jan?)
> the strategy itself does no locking at all. Like the old LRU code it
> simp
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Manfred Spraul wrote:
I remember there were patches that tried other algorithms instead of the
simple LRU for the buffer manager. Has anyone tried to change the
locking of the buffer manager?
CVS HEAD already has an Adap
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Manfred Spraul wrote:
>> I remember there were patches that tried other algorithms instead of the
>> simple LRU for the buffer manager. Has anyone tried to change the
>> locking of the buffer manager?
> CVS HEAD already has an Adaptive Replacement Cach
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Mark ran a DBT-2 testrun with the attached statistics patch applied: It
> collects stats about all lightweight locks and dumps them during
> shutdown. The hottest locks are
> Lock Acquire%contention sleep calls
> 8(WALInsertLo
On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address
Dear all:
This may not be the right list to refer to the rpm,
but I am confident that someone on this list will be
able to point me in the right direction.
I am trying to make sure when this rpm is installed,
it installs to /opt/postgresql-7.2.4/ in stead of
/usr/bin, /usr/man etcetera (this is th
Sai Hertz And Control Systems wrote:
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
For all monetary values the P
Sai Hertz And Control Systems wrote:
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
If you would like to know wh
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
If you would like to know whats IEEE 754 read this
http://docs.sun
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
How about (even quicker and dirtier) putting a limited loop (say 5
iterations?) with a small delay in it around the check for whether or
not we are the only connection? Createdb is hardly a time critical
operation, and taking a few s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How about (even quicker and dirtier) putting a limited loop (say 5
> iterations?) with a small delay in it around the check for whether or
> not we are the only connection? Createdb is hardly a time critical
> operation, and taking a few seconds extra
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Longer term, a robust mechanism for DB level locks would probably be
preferable, I guess, so I'm not sure if my idea is worth doing in the
mean time. Presumably it hasn't caused much of a problem up to now,
since most people are not
*growl* - it sounds like the business...and I was all set to code it,
however after delving into Pg's aggregation structure a bit, it suffers
a fatal flaw :
There appears to be no way to avoid visiting every row when defining an
aggregate (even if you do nothing on each one) -- which defeats th
On Sat, 27 Dec 2003, A E wrote:
> Hi,
>
> I was wondering if a solution was ever found to the error: "wrong record type
> supplied in RETURN NEXT" when executing a function that returns the Record datatype?
> I have seen a couple of previous post from Tom Lane and others, but no real
> resolu
14 matches
Mail list logo
