Re: pg_dump dump catalog ACLs
От | Noah Misch |
---|---|
Тема | Re: pg_dump dump catalog ACLs |
Дата | |
Msg-id | 20160421023318.GA2020752@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: pg_dump dump catalog ACLs (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_dump dump catalog ACLs
|
Список | pgsql-hackers |
On Wed, Apr 20, 2016 at 11:12:44AM -0400, Stephen Frost wrote: > * Noah Misch (noah@leadboat.com) wrote: > > On Sun, Apr 17, 2016 at 11:02:28PM -0400, Noah Misch wrote: > > > (3) pg_dumpall became much slower around the time of these commits. On one > > > machine (POWER7 3.55 GHz), a pg_dumpall just after initdb slowed from 0.25s at > > > commit 6c268df^ to 4.0s at commit 7a54270. On a slower machine (Opteron > > > 1210), pg_dumpall now takes 19s against such a fresh cluster. > > > > [This is a generic notification.] > > > > The above-described topic is currently a PostgreSQL 9.6 open item. Stephen, > > since you committed the patch believed to have created it, you own this open > > item. If that responsibility lies elsewhere, please let us know whose > > responsibility it is to fix this. Since new open items may be discovered at > > any time and I want to plan to have them all fixed well in advance of the ship > > date, I will appreciate your efforts toward speedy resolution. Please > > present, within 72 hours, a plan to fix the defect within seven days of this > > message. Thanks. > > I'm at PGConf.US but will be reviewing this in detail after. The schema > qualification will be easily taken care of, the additional time for > pg_dump is due to the queries looking at the catalog objects and is > therefore relatively fixed and is primairly only a large amount of the > time when dumping databases which are mostly empty. Do you think it would be okay to release 9.6 with pg_dump still adding that amount of time per database?
В списке pgsql-hackers по дате отправления: