Re: pg_dump in a production environment

Поиск
Список
Период
Сортировка
Искать
От
Thomas F. O'Connell
Тема
Re: pg_dump in a production environment
Дата
в 17:58:25
Msg-id
6B48B131-7171-4F4A-9DE3-CD8F4400F7A5@sitening.com
Ответ на
Список
Дерево обсуждения
Re: pg_dump in a production environment "Thomas F. O'Connell" <tfo@sitening.com>
Re: pg_dump in a production environment Chris Kratz <chris.kratz@vistashare.com>
Re: pg_dump in a production environment Scott Marlowe <smarlowe@g2switchworks.com>
Re: pg_dump in a production environment Chris Kratz <chris.kratz@vistashare.com>
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 по дате отправления
От: Thomas F. O'Connell
Дата:
От: Scott Marlowe
Дата:
FAQ