Re: Potential bug in pg_dump ...
От | Tom Lane |
---|---|
Тема | Re: Potential bug in pg_dump ... |
Дата | |
Msg-id | 3459.1010791811@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Potential bug in pg_dump ... (Brent Verner <brent@rcfile.org>) |
Ответы |
Re: Potential bug in pg_dump ...
|
Список | pgsql-hackers |
Brent Verner <brent@rcfile.org> writes: > Attached is a patch that implements table locking for pg_dump. Checked and applied, with some small tweaking. I broke the outer loop of getTables() into two loops, one that extracts data from the pg_class SELECT result and locks the target tables, and a second one that does the rest of the stuff that that routine does. This is to minimize the time window between doing the pg_class SELECT and locking the tables. In testing this thing, I noticed that pg_dump spends a really unreasonable amount of time on schema extraction. For example, on the regression database the actual COPY commands take less than a quarter of the runtime. (Of course, regression deliberately doesn't contain huge volumes of data, so this case may be unrepresentative of real-world situations.) The retail queries to get table attributes, descriptions, etc are probably the cause. Something to think about improving someday... regards, tom lane
В списке pgsql-hackers по дате отправления: