Re: need advice to tune postgresql

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Darius Pėža <darius(at)onrails(dot)lt>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: need advice to tune postgresql
Date: 2018-02-23 15:26:55
Message-ID: 1519399615.2530.14.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Darius Pėža wrote:
> I have issue that update queries is slow, I need some advice how improve speed. I don't have much control to change queries. But I can change postresql server configuration
>
> query example:
>
> UPDATE "project_work" SET "left" = ("project_work"."left" + 2) WHERE ("project_work"."left" >= 8366)
>
> sometimes updated lines count is up to 10k
>
> postgresql version 9.3
>
> postgresl.conf
> max_connections = 100
> shared_buffers = 6GB # min 128kB
> work_mem = 100MB # min 64kB
>
> all other values are default
>
> server hardware
> Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
> 16GB RAM
> disk is HDD
>
> about half of resource I can dedicate for postgresql server.

If the number of updated lines is that big, you should try to
get HOT updates as much as possible.

For that, make sure that there is *no* index on the column,
and that the fillfactor for the table is suitably low (perhaps 50).

During a HOT update, when the new row version fits into the same
page as the old one, the indexes don't have to be updated.
That will speed up the UPDATE considerably.

On the other hand, an UPDATE like yours would then always use a
sequential scan, but that may still be a net win.

Other than that, setting checkpoint_segments high enough that
you don't get too many checkpoints can help.

Of course, more RAM and fast storage are always good.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Vitaliy Garnashevich 2018-02-23 15:35:06 Re: effective_io_concurrency on EBS/gp2
Previous Message Rick Otten 2018-02-23 15:23:03 Re: effective_io_concurrency on EBS/gp2