work_mem + refresh mat view concurrently performance

From: "Wetmore, Matthew (CTR)" <Matthew(dot)Wetmore(at)express-scripts(dot)com>
To: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: work_mem + refresh mat view concurrently performance
Date: 2023-06-22 16:49:47
Message-ID: 8414ad71bc6d48c0864a944960b87aec@express-scripts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

My experience on a large mat view, if you have parallel set up, drop the mat view and recreate since CREATE is available for parallel.

It’s the concurrently that slows things down without the locks.

I would try session work_men in sandbox first, depending on how long the view refresh takes, as a sharp increase could affect memory for other stuff or have server impact

From: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
Sent: Thursday, June 22, 2023 9:02 AM
To: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: [EXTERNAL] work_mem + refresh mat view concurrently performance

Is there any relationship here? Wondering if increasing the former to a large amount for a session (2gb?) would help the joins/hashing/etc of the mat view refresh. Or if this is just nonsense.

Looking for some gains in refreshing if possible.

--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com<mailto:wellsoliver(at)gmail(dot)com>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Wetmore, Matthew (CTR) 2023-06-22 20:00:31 GENERATE AS
Previous Message Laurenz Albe 2023-06-22 16:08:59 Re: work_mem + refresh mat view concurrently performance