Hello!
I have a postgresql server serving thousands of tables. Sometime there are
queries which involves several tables.
In postgresql.conf I have these settings:
shared_buffers = 4
work_mem = 8192
maintenance_work_mem = 16384
max_stack_depth = 2048
all other settings are left by default
Unsubscribe
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Diego Gaviola
Sent: Tuesday, June 27, 2006 4:15
AM
To:
pgsql-performance@postgresql.org
Subject: [PERFORM] unsubscribe
unsubscribe
On 7/6/06, A. Kretschmer [EMAIL PROTECTED] wrote:
am 06.07.2006, um 9:40:16 +0300 mailte Eugeny N Dzhurinsky folgendes:
In postgresql.conf I have these settings:
shared_buffers = 4
work_mem = 8192
maintenance_work_mem = 16384
max_stack_depth = 2048
all other settings are left by
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
On 7/5/06, andy rost [EMAIL PROTECTED] wrote:
fsync = on # turns forced synchronization
have you tried turning this off and measuring performance?
stats_command_string = on
I would turn this off unless you absoltely require it. It is
expensive for what it
On Thu, Jul 06, 2006 at 09:28:39AM -0500, Scott Marlowe wrote:
On Thu, 2006-07-06 at 01:40, Eugeny N Dzhurinsky wrote:
Do you add / remove tables a lot? Could be you've got system catalog
bloat.
Yes, almost each table is dropped and re-created in 3-5 days.
do you have autovacuum running?
On 7/6/06, Eugeny N Dzhurinsky [EMAIL PROTECTED] wrote:
Hello!
I have a postgresql server serving thousands of tables. Sometime there are
queries which involves several tables.
In postgresql.conf I have these settings:
shared_buffers = 4
work_mem = 8192
maintenance_work_mem = 16384
On Thu, 2006-07-06 at 10:11, Eugeny N Dzhurinsky wrote:
On Thu, Jul 06, 2006 at 09:28:39AM -0500, Scott Marlowe wrote:
On Thu, 2006-07-06 at 01:40, Eugeny N Dzhurinsky wrote:
Do you add / remove tables a lot? Could be you've got system catalog
bloat.
Yes, almost each table is dropped
-- Lorenzo PasquinelliSoftware Developer
My grandfather once told me that there are two kinds of people: thosewho work and those who take the credit. He told me to try to be in thefirst group; there was less competition there.- Indira Gandhi
with all these unsubscribe requests, we can only extrapolate that the
server has no serious performance issues left to solve. good work!
:-)
merlin
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Thanks for the suggestion Mark, though the server chassis I am trying to
utilize already has 4 10,000 RPM SCSI drives with SCA interfaces. Ideally I
would like to use the existing drives and chassis and find another SCSI RAID
controller. It looks like 3Ware only makes ATA controllers.
-Kenji
On
On Thu, 2006-07-06 at 13:10, Kenji Morishige wrote:
Thanks for the suggestion Mark, though the server chassis I am trying to
utilize already has 4 10,000 RPM SCSI drives with SCA interfaces. Ideally I
would like to use the existing drives and chassis and find another SCSI RAID
controller. It
Take a look at: http://www.icp-vortex.com/english/index_e.htm
They have always made good RAID controllers.
Cheers
Paul
On Thu, 2006-07-06 at 11:10 -0700, Kenji Morishige wrote:
Thanks for the suggestion Mark, though the server chassis I am trying to
utilize already has 4 10,000 RPM SCSI
Kenji Morishige wrote:
Thanks for the suggestion Mark, though the server chassis I am trying to
utilize already has 4 10,000 RPM SCSI drives with SCA interfaces. Ideally I
would like to use the existing drives and chassis and find another SCSI RAID
controller. It looks like 3Ware only makes
I have a problem with a query that in postgres 7.4 and 8.12 has an acceptable response time but in postgres 8.14 is very slow. This is the table I use:create table TEST ( TESTID INT8 not null, TESTTYPE INT4 null, constraint PK_TESTID primary key
Ioana Danes wrote:
I have a problem with a query that in postgres 7.4 and 8.12 has an
acceptable response time but in postgres 8.14 is very slow.
This is the table I use:
*
create* *table* TEST (
TESTIDINT8 *not* *null*,
TESTTYPE INT4 *null*,
*constraint* PK_TESTID *primary* *key*
If I insert a bunch of rows, then truncate, then insert a bunch more rows, do I
need to vacuum? I've been assuming that TRUNCATE TABLE is a brute-force
technique that more-or-less tosses the old table and starts fresh so that no
vacuum is necessary.
Second question: Same scenario as above,
--On July 6, 2006 2:21:15 PM -0400 Paul Khavkine
[EMAIL PROTECTED] wrote:
Take a look at: http://www.icp-vortex.com/english/index_e.htm
They have always made good RAID controllers.
I'll give a huge thumbs up for the ICPs, and also make sure you get the BBU
cache as well (batter
19 matches
Mail list logo
