Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Subject: Re: Pg_dump
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: <404a126a-6229-7d83-9b86-70304a5693bc@jakobs.com>
Date: Thu, 7 Dec 2023 11:26:15 -0700
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <370989DB-26AD-451A-AF28-C4752E08FE77@elevated-dev.com>
References: 
 <CAJk5AtZX23PBG4rfrVt6cp3z_pYGtEE5JvvCRG6Lj3F7=1+C2Q@mail.gmail.com>
 <404a126a-6229-7d83-9b86-70304a5693bc@jakobs.com>
To: Rajesh Kumar <rajeshkumar.dba09@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/370989DB-26AD-451A-AF28-C4752E08FE77%40elevated-dev.com>
Precedence: bulk

> Readers don't block writers, writers don't block readers in =
PostgreSQL.
>=20
> pg_dump is a reader.
>=20
> --=20
> Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012

Additionally, I've done some stress testing and found that pg_dump puts =
surprisingly low load on our dbs. Of course, like everything else, this =
dependent on your specifics--after all the dump will require reading all =
rows, so for instance if you're disk-bound, you could see a performance =
hit. But generally, if your db is running in a reasonably "healthy" =
performance range and not already close to limits, pg_dump won't have a =
performance impact visible to users.