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 "s
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:
> I’m 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 rela
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
++ Je
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 broadcast)-
Steinar wrote:
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...
I totally agree on that.
--
Cosimo
---(end of broadcast)--
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 consider
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
"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 bloat
Hi All,
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
/raid02/databases-8.0.0/pg_xlog
/var/lib/pgs
"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_
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 sy
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 followi
"Keith Worthington" <[EMAIL PROTECTED]> writes:
> On Wed, 01 Jun 2005 12:19:40 -0400, Tom Lane wrote
>> Put the xlog anywhere BUT there!
> Is there a convention that most people follow. It would seem that
> anywhere in the installation directory is a bad idea. From what I
> have read on
Tom Lane wrote:
...
Now that I think about it, you were (if I understood your layout
correctly) proposing to put the xlog on your system's root disk.
This is probably a bad idea for performance, because there will always
be other traffic to the root disk. What you are really trying to
accomplis
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 par
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 pl
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 be
John A Meinel <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Now that I think about it, you were (if I understood your layout
>> correctly) proposing to put the xlog on your system's root disk.
>> This is probably a bad idea for performance, ...
> I certainly agree with what you wrote. But my un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Davis wrote:
| I have five PC's accessing a PG database that is mounted on a
| Dell Windows 2003 server. The PC's are accessing the database with a
| Fujitsu cobol program via ODBC (all machines have same (newest) ODBC
| driver from PG). 2 of
23 matches
Mail list logo
