| 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: | Whole Thread | Raw Message | 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
| 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 |