pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedCOPY write load on primary impacting replica?
3+ messages / 3 participants
[nested] [flat]
* COPY write load on primary impacting replica?
@ 2022-01-20 01:27 Wells Oliver <wells.oliver@gmail.com>
0 siblings, 2 replies; 3+ messages in thread
From: Wells Oliver @ 2022-01-20 01:27 UTC (permalink / raw)
To: pgsql-admin
Hi: I have an issue where a big big big COPY is thrashing a disk on a DB,
my idea was to fire up a read replica of this DB and point my users to it
for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage
caused by COPY on the primary.
Wondering if this is foolish, whether the WAL log stuff would cause equal
disk usage on the replica.
Thanks!
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: COPY write load on primary impacting replica?
@ 2022-01-20 02:01 Licio Matos <licio.matos@gmail.com>
parent: Wells Oliver <wells.oliver@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Licio Matos @ 2022-01-20 02:01 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; +Cc: pgsql-admin
Why not make the COPY in small batch and intervals of seconds between them?!
Like COPY 10000 and wait 60 seconds for another batch.
On Wed, 19 Jan 2022 at 22:28 Wells Oliver <wells.oliver@gmail.com> wrote:
> Hi: I have an issue where a big big big COPY is thrashing a disk on a DB,
> my idea was to fire up a read replica of this DB and point my users to it
> for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage
> caused by COPY on the primary.
>
> Wondering if this is foolish, whether the WAL log stuff would cause equal
> disk usage on the replica.
>
> Thanks!
>
>
> --
> Wells Oliver
> wells.oliver@gmail.com <wellsoliver@gmail.com>
>
--
Licio Matos
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: COPY write load on primary impacting replica?
@ 2022-01-20 07:57 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Wells Oliver <wells.oliver@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Laurenz Albe @ 2022-01-20 07:57 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; pgsql-admin
On Wed, 2022-01-19 at 17:27 -0800, Wells Oliver wrote:
> Hi: I have an issue where a big big big COPY is thrashing a disk on a DB,
> my idea was to fire up a read replica of this DB and point my users to it
> for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage
> caused by COPY on the primary.
>
> Wondering if this is foolish, whether the WAL log stuff would cause equal
> disk usage on the replica.
That is a feasible idea.
Make sure to set "max_standby_streaming_delay" high enough that COPY
won't get canceled.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-01-20 07:57 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-01-20 01:27 COPY write load on primary impacting replica? Wells Oliver <wells.oliver@gmail.com>
2022-01-20 02:01 ` Licio Matos <licio.matos@gmail.com>
2022-01-20 07:57 ` Laurenz Albe <laurenz.albe@cybertec.at>
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