Re: PostgreSQL performance problem -> tuning - Mailing list pgsql-performance

From Tom Lane
Subject Re: PostgreSQL performance problem -> tuning
Date
Msg-id 1566.1060193599@sss.pgh.pa.us
Whole thread Raw
In response to PostgreSQL performance problem -> tuning  (Yaroslav Mazurak <yamazurak@Lviv.Bank.Gov.UA>)
List pgsql-performance
Yaroslav Mazurak <yamazurak@Lviv.Bank.Gov.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL performance problem -> tuning
Next
From: Sebastien Lemieux
Date:
Subject: How to efficiently duplicate a whole schema?