Re: pg_dump in a production environment
От | Thomas F. O'Connell |
---|---|
Тема | Re: pg_dump in a production environment |
Дата | |
Msg-id | 6B48B131-7171-4F4A-9DE3-CD8F4400F7A5@sitening.com обсуждение исходный текст |
Ответ на | Re: pg_dump in a production environment (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: pg_dump in a production environment
|
Список | 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 по дате отправления: