| From: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com> |
|---|---|
| To: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
| Cc: | PgSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pg_dump in a production environment |
| Date: | 2005-05-23 20:58:15 |
| Message-ID: | 6B48B131-7171-4F4A-9DE3-CD8F4400F7A5@sitening.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2005-05-23 21:09:50 | Re: pg_dump in a production environment |
| Previous Message | Thomas F. O'Connell | 2005-05-23 20:56:32 | Re: pg_dump in a production environment |