Re: [PERFORM] Postgres server crash

Craig A. James wrote: For the third time today, our server has crashed, or frozen, actually something in between. Normally there are about 30-50 connections because of mod_perl processes that keep connections open. After the crash, there are three processes remaining: # ps -ef | grep postgr

[PERFORM] Postgres server crash

For the third time today, our server has crashed, or frozen, actually something in between. Normally there are about 30-50 connections because of mod_perl processes that keep connections open. After the crash, there are three processes remaining: # ps -ef | grep postgres postgres 23832 1

Re: [PERFORM] Hundreds of database and FSM

On Wed, Nov 15, 2006 at 02:31:45PM -0300, Alvaro Herrera wrote: >> This is based on our current 150 databases times 20 tables, or 3000 tables >> total. But I wasn't sure if sequences count as "relations", which would >> double the number. > They don't because they don't have free space. OTOH, i

Re: [PERFORM] Hundreds of database and FSM

Craig A. James wrote: > This is based on our current 150 databases times 20 tables, or 3000 tables > total. But I wasn't sure if sequences count as "relations", which would > double the number. They don't because they don't have free space. -- Alvaro Herreraht

[PERFORM] Hundreds of database and FSM

A few months ago a couple guys got "bragging rights" for having the most separate databases. A couple guys claimed several hundred databases and one said he had several thousand databases. The concensus was that Postgres has no problem handling many separate databases. I took that to heart a

Re: [PERFORM] Slow SELECT on three or more clients

Hi, Amir, AMIR FRANCO D. JOVEN wrote: > My current project uses PostgreSQL 7.3.4. By all means, please upgrade. The newest 7.3 series version is 7.3.16, which fixes lots of critical bugs, and can be used as a drop-in replacement for 7.3.4 (see Release Notes at http://www.postgresql.org/docs/7.3

Re: [PERFORM] Slow SELECT on three or more clients

On 11/15/06, AMIR FRANCO D. JOVEN <[EMAIL PROTECTED]> wrote: Hi! Im new to PostgreSQL. My current project uses PostgreSQL 7.3.4. the problem is like this: I have a table with 94 fields and a select with only one resultset in only one client consumes about 0.86 seconds. The client execute

Re: [PERFORM] Slow SELECT on three or more clients

Operating system and some of the basic PostreSQL config settings would be helpful, plus any info you have on your disks, the size of the relevant tables, their structure and indexes & vacuum/analyze status ... plus what others have said: Upgrade! There are considerable improvements in, well, *

Re: [PERFORM] Slow SELECT on three or more clients

AMIR FRANCO D. JOVEN wrote: Hi! Im new to PostgreSQL. My current project uses PostgreSQL 7.3.4. Upgrading your version of PostgreSQL to 8.1 will give you significant benefits to performance. the problem is like this: I have a table with 94 fields and a select with only one resultset in onl

Re: [PERFORM] Slow SELECT on three or more clients

* AMIR FRANCO D. JOVEN <[EMAIL PROTECTED]> [061115 12:44]: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. Ancient. Upgrade it, especially if it's a new database. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset

[PERFORM] Slow SELECT on three or more clients

Hi! Im new to PostgreSQL. My current project uses PostgreSQL 7.3.4. the problem is like this: I have a table with 94 fields and a select with only one resultset in only one client consumes about 0.86 seconds. The client executes three 'select' statements to perform the task which consumes 2.58

Re: [PERFORM] Context switch storm

On Tue, 2006-11-14 at 09:17 -0500, Merlin Moncure wrote: > On 11/14/06, Cosimo Streppone <[EMAIL PROTECTED]> wrote: > > I must say I lowered "shared_buffers" to 8192, as it was before. > > I tried raising it to 16384, but I can't seem to find a relationship > > between shared_buffers and performanc