From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Potential bug in pg_dump ... |
Date: | 2002-01-11 23:30:11 |
Message-ID: | 3459.1010791811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brent Verner <brent(at)rcfile(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brent Verner | 2002-01-12 02:10:04 | Re: Potential bug in pg_dump ... |
Previous Message | Don Baccus | 2002-01-11 19:42:38 | Re: again on index usage |