Re: Slow system due to ReorderBufferGetTupleBuf?

From: Martin Moore <martin(dot)moore(at)avbrief(dot)com>
To: <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Slow system due to ReorderBufferGetTupleBuf?
Date: 2018-01-02 12:09:04
Message-ID: 9097DCB4-E742-46A9-B72D-D902598CD1FC@avbrief.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 01/01/2018, 17:45, "Peter Geoghegan" <pg(at)bowt(dot)ie> wrote:

On Mon, Jan 1, 2018 at 8:56 AM, Martin Moore <martin(dot)moore(at)avbrief(dot)com> wrote:
> Can someone shed some light on this and advise how to prevent it reoccurring?

You're using v10, which has these two commits:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=58b25e98106dbe062cec0f3d31d64977bffaa4af

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9fab40ad32efa4038d19eaed975bb4c1713ccbc0

Unfortunately, per the commit message of the first commit, it doesn't
look like the tuple allocator uses any new strategy, at least until
this v11 commit:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a4ccc1cef5a04cc054af83bc4582a045d5232cb3

My guess is that that would make a noticeable difference, once v11
becomes available. Could you test this yourself by building from the
master branch?

--
Peter Geoghegan

Thanks Peter. I don’t really want to go down that route for various reasons. There’s a task that copies ‘old’ rows to various old_ tables and then deletes from the main tables, then does a vaccum and analyse. Tables only have 20-30k rows. I’m guessing this may be the trigger for the problem so have changed the timing from every 20 mins to once in the middle of the night when things are quiet.

Would this explain the problem?

Martin.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Durumdara 2018-01-02 12:22:16 Re: Select for update / deadlock possibility?
Previous Message Tatsuo Ishii 2018-01-02 12:01:16 Re: PGPool encrypted connections from Application