I have in my possession some performance tuning documents authored by Bruce
Momjian, Josh Berkus, and others. They give good information on utilities to
use (like ipcs, sar, vmstat, etc) to evaluate disk, memory, etc. performance
on Unix-based systems.
Problem is, I have applications running on Wi
I am running version 8.0.1 on Windows 2003. I have an application that
subjects PostgreSQL to sudden bursts of activity at times which cannot be
predicted. The bursts are significant enough to cause performance
degradation, which can be fixed by a 'vacuum analyze'.
I am aware of the existence and
... to do the following:
(1) Make a table memory-resident only ?
(2) Set up user variables in memory that are persistent across all
sessions, for
as long as the database is up and running ?
(3) Assure that a disk-based table is always in memory (outside of keeping
it in
memory buf
On 2005-09-30 01:21, Lane Van Ingen wrote:
> (3) Assure that a disk-based table is always in memory (outside of
keeping
> it in
> memory buffers as a result of frequent activity which would prevent
> LRU
> operations from taking it out) ?
I was wondering about t
I have an application that is prone to sudden, unscheduled high bursts of
activity, and
I am finding that the application design permits me to detect the activity
bursts within
an existing function. The bursts only affect 3 tables, but degradation
becomes apparent
after 2,000 updates, and significa
I believe it would be much
better
to be able to call VACUUM out of a function, the same way in which other SQL
commands are used.
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Friday, October 07, 2005 3:53 AM
To: Lane Van Ingen
Cc: pgsql-performance@postgresql.o
Does anybody know if it is possible to use the statistics collected by
PostgreSQL to do the following, and how?
- view all locks held by a particular PostgreSQL session (including how to
determine
the session ID#)
- determine effect of lock contention on overall database performance, as
well as
