Re: PostgreSQL performance problem -> tuning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yaroslav Mazurak <yamazurak(at)Lviv(dot)Bank(dot)Gov(dot)UA>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL performance problem -> tuning
Date: 2003-08-06 18:13:19
Message-ID: 1566.1060193599@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Yaroslav Mazurak <yamazurak(at)Lviv(dot)Bank(dot)Gov(dot)UA> writes:
> Current postgresql.conf settings (some) are:

> max_locks_per_transaction = 16

This strikes me as a really bad idea --- you save little space by
reducing it from the default, and open yourself up to unexpected failures.

> wal_buffers = 256

That is almost certainly way more than you need.

> sort_mem = 131072

People have already told you that one's a bad idea.

> commit_delay = 32000

I'm unconvinced that setting this nonzero is a good idea. Have you done
experiments to prove that you get a benefit?

> enable_seqscan = false

This is the cause of the bizarre-looking cost estimates. I don't
recommend setting it false as a system-wide setting. If you want
to nudge the planner towards indexscans, reducing random_page_cost
a little is probably a better way.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-08-06 18:16:47 Re: PostgreSQL performance problem -> tuning
Previous Message Wilson A. Galafassi Jr. 2003-08-06 18:03:41 PostgreSql under Linux