Hi,
On 2020-02-13 16:16:14 -0500, Tom Lane wrote:
> In principle perhaps we could improve the granularity of dead-row
> detection, so that if a row version is both created and deleted by
> the current transaction, and we have no live snapshots that could
> see it, we could go ahead and mark the ro
On 2020-Feb-19, Lars Aksel Opsahl wrote:
> With the values above I did see same performance problems and we ended
> with a lot of subtransControlLock.
>
> So I started to change the code based on your feedbacks.
>
> - What seems to work very good in combination with a catch exception
> and retry
On Wed, Feb 19, 2020 at 05:42:41AM +0100, Nicolas PARIS wrote:
> Hi
>
> I have both hdd and ssd disk on the postgres server. The cluster is
> right now created on the hdd only. I am considering using a tablespace
> to put some highly used postgres object on the ssd disk. Of course the
> ssd is sma
Hi
>From: Laurenz Albe
>Sent: Tuesday, February 18, 2020 6:27 PM
>ATo: Pavel Stehule ; Tom Lane
>Cc: Lars Aksel Opsahl ;
>pgsql-performance@lists.postgresql.org
>Subject: Re: SubtransControlLock and performance problems
>
>Did you have several concurrent
On Wed, 2020-02-19 at 05:42 +0100, Nicolas PARIS wrote:
> I have both hdd and ssd disk on the postgres server. The cluster is
> right now created on the hdd only. I am considering using a tablespace
> to put some highly used postgres object on the ssd disk. Of course the
> ssd is small compared to
Unless this is about reads exclusively I would start with putting wal on
ssd.
What you might also do, is create separate filesystems (lvm). You can then
keep track of io with iostat per filesystem and see what would benefit
most. And see storage size usage also.
And you could use lvm to move filesy
