Cosimo Streppone wrote:
# Config
/etc/sysctl.conf:
kernel.shmall = 786432000
kernel.shmmax = 786432000
I think you have a problem here.
kernel.shmmax should *not* be set to an amount of RAM, but
to maximum number of shared memory pages, which on a typical linux system
is
Cosimo Streppone wrote:
Mark Kirkwood ha scritto:
Cosimo Streppone wrote:
# Config
/etc/sysctl.conf:
kernel.shmall = 786432000
kernel.shmmax = 786432000
I think you have a problem here.
kernel.shmmax should *not* be set to an amount of RAM, but
Sorry, I thought
Hello,
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
Database size should be more or less constant but it
has high turnover rate (100+ insert/update/delete per second).
Hi John,
thank you very much for the answer :). I moved the pg_xlog to another
partition and made a symlink to it. Know the database is much more
faster than before. A sample select which was finished in 68seconds
before, is now finished in 58seconds :).
I will test the other changes today also
On Tue, 2005-05-31 at 11:37 +0200, Praveen Raja wrote:
Im trying to move an existing solution from MySQL to PostgreSQL. As
it is now the solution has 4 tables where data in inserted by an
application. At regular intervals (10min) data from these tables is
consolidated and moved to another
On Fri, 2005-05-27 at 07:52 -0500, Josh Close wrote:
Setting shared buffers above something like 10-30% of memory is counter
productive.
What is the reason behind it being counter productive? If shared
buffers are at 30%, should effective cache size be at 70%? How do
those two relate?
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
But INT2, INT4, INT8 and SERIAL are considered to be a unique datatype.
Am I Right?
Thanks,
Marc
--
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++
On Wed, Jun 01, 2005 at 07:30:37AM +0200, Cosimo Streppone wrote:
fsync = true
false
Just setting fsync=false without considering the implications is a _bad_
idea...
/* Steinar */
--
Homepage: http://www.sesse.net/
---(end of
Yes, i think also that this setting should be enabled :).
Am Mittwoch, den 01.06.2005, 11:57 +0200 schrieb Steinar H. Gunderson:
On Wed, Jun 01, 2005 at 07:30:37AM +0200, Cosimo Streppone wrote:
fsync = true
false
Just setting fsync=false without considering the
On Wed, Jun 01, 2005 at 11:45:06AM +0200, Marc Mamin wrote:
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
But INT2, INT4, INT8 and SERIAL are considered to be a unique datatype.
Am I Right?
No, they weren't when
Mindaugas Riauba [EMAIL PROTECTED] writes:
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
First thing I'd suggest is to get a more detailed idea of exactly
what is bloating
Keith Worthington [EMAIL PROTECTED] writes:
I have been reading about increasing PostgreSQL performance by relocating the
pg_xlog to a disk other than the one where the database resides. I have the
following pg_xlogs on my system.
/raid02/databases/pg_xlog
/raid02/rhdb_databases/pg_xlog
On Wed, 01 Jun 2005 12:19:40 -0400, Tom Lane wrote
Keith Worthington [EMAIL PROTECTED] writes:
I have been reading about increasing PostgreSQL performance
by relocating the pg_xlog to a disk other than the one
where the database resides. I have the following pg_xlogs
on my system.
Keith Worthington wrote:
On Wed, 01 Jun 2005 12:19:40 -0400, Tom Lane wrote
Keith Worthington [EMAIL PROTECTED] writes:
I have been reading about increasing PostgreSQL performance
by relocating the pg_xlog to a disk other than the one
where the database resides. I have the following
Is it any way to attempt to force the planner to use some specific index
while creating the plan? Other than eventually dropping all the other
indices (which is obiously not a solution in production setting anyway)?
I have one case where I have added 16 indices to a table, many of them
beeing
We're in the process of buying another Opteron server to run Postgres, and
based on the suggestions in this list I've asked our IT director to get an
LSI MegaRaid controller rather than one of the Adaptecs.
But when we tried to place our order, our vendor (Penguin Computing) advised
us:
we find
Stacy White presumably uttered the following on 06/01/05 23:42:
We're in the process of buying another Opteron server to run Postgres, and
based on the suggestions in this list I've asked our IT director to get an
LSI MegaRaid controller rather than one of the Adaptecs.
But when we tried to
I've used LSI MegaRAIDs successfully in the following systems with both
Redhat 9 and FC3 64bit.
Arima HDAMA/8GB RAM
Tyan S2850/4GB RAM
Tyan S2881/4GB RAM
I've previously stayed away from Adaptec because we used to run Solaris
x86 and the driver was somewhat buggy. For Linux and FreeBSD, I'd
18 matches
Mail list logo
