Skip to main content
Commonmark migration
Source Link

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1]pg_repack instead which achieves the same without exclusive locks.

Related:

None of this affects the size of backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1] instead which achieves the same without exclusive locks.

Related:

None of this affects the size of backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool pg_repack instead which achieves the same without exclusive locks.

Related:

None of this affects the size of backups, since those do not include dead rows to begin with.

deleted 2 characters in body
Source Link
Erwin Brandstetter
  • 182.1k
  • 28
  • 457
  • 620

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1] instead which achieves the same without exclusive locks.

Related:

None of this affects the size of a backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1] instead which achieves the same without exclusive locks.

Related:

None of this affects the size of a backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1] instead which achieves the same without exclusive locks.

Related:

None of this affects the size of backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack

Source Link
Erwin Brandstetter
  • 182.1k
  • 28
  • 457
  • 620

It's a busy server of a local social networking website. No time is actually "downtime".

So VACUUM FULL is going to be a problem since it takes an exclusive lock on each table it processes. Consider the community tool [pg_repack][1] instead which achieves the same without exclusive locks.

Related:

None of this affects the size of a backups, since those do not include dead rows to begin with. [1]: https://github.com/reorg/pg_repack