pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedwork_mem + refresh mat view concurrently performance
3+ messages / 3 participants
[nested] [flat]
* work_mem + refresh mat view concurrently performance
@ 2023-06-22 16:02 Wells Oliver <wells.oliver@gmail.com>
0 siblings, 2 replies; 3+ messages in thread
From: Wells Oliver @ 2023-06-22 16:02 UTC (permalink / raw)
To: pgsql-admin
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.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: work_mem + refresh mat view concurrently performance
@ 2023-06-22 16:08 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Wells Oliver <wells.oliver@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Laurenz Albe @ 2023-06-22 16:08 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; pgsql-admin
On Thu, 2023-06-22 at 09:02 -0700, Wells Oliver wrote:
> 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.
Sure: if the query runs faster, the view can refresh faster.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 3+ messages in thread
* work_mem + refresh mat view concurrently performance
@ 2023-06-22 16:49 Wetmore, Matthew (CTR) <Matthew.Wetmore@express-scripts.com>
parent: Wells Oliver <wells.oliver@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Wetmore, Matthew (CTR) @ 2023-06-22 16:49 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; 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.oliver@gmail.com>
Sent: Thursday, June 22, 2023 9:02 AM
To: pgsql-admin <pgsql-admin@postgresql.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.oliver@gmail.com<mailto:wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2023-06-22 16:49 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-22 16:02 work_mem + refresh mat view concurrently performance Wells Oliver <wells.oliver@gmail.com>
2023-06-22 16:08 ` Laurenz Albe <laurenz.albe@cybertec.at>
2023-06-22 16:49 ` Wetmore, Matthew (CTR) <Matthew.Wetmore@express-scripts.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox