Re: pg_dump in a production environment - Mailing list pgsql-general

From Thomas F. O'Connell
Subject Re: pg_dump in a production environment
Date
Msg-id 6B48B131-7171-4F4A-9DE3-CD8F4400F7A5@sitening.com
Whole thread Raw
In response to Re: pg_dump in a production environment  (Scott Marlowe <smarlowe@g2switchworks.com>)
Responses Re: pg_dump in a production environment
List pgsql-general
A note about database design, though: there are thousands of tables
in this database, most of them inherited. I haven't looked at the
internals of pg_dump, but generally, how do the sequential scans
work? Why would these prevent the tables from being accessed by
queries that don't require exclusive locks?

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On May 23, 2005, at 3:18 PM, Scott Marlowe wrote:

> Basically, it sounds like postgresql is doing a lot of very long
> sequential scans to do this backup.  HAve you done a vacuum full
> lately?  It could be that you've got a lot of table bloat that's
> making
> the seq scans take so long.

pgsql-general by date:

Previous
From: "Thomas F. O'Connell"
Date:
Subject: Re: pg_dump in a production environment
Next
From: Scott Marlowe
Date:
Subject: Re: pg_dump in a production environment