From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump issues |
Date: | 2011-10-03 15:39:05 |
Message-ID: | 4E89D719.80705@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/03/2011 12:47 AM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> While investigating a client problem I just observed that pg_dump takes
>> a surprisingly large amount of time to dump a schema with a large number
>> of views. The client's hardware is quite spiffy, and yet pg_dump is
>> taking many minutes to dump a schema with some 35,000 views. Here's a
>> simple test case:
>> create schema views;
>> do 'begin for i in 1 .. 10000 loop execute $$create view views.v_$$
>> || i ||$$ as select current_date as d, current_timestamp as ts,
>> $_$a$_$::text || n as t, n from generate_series(1,5) as n$$; end
>> loop; end;';
>> On my modest hardware this database took 4m18.864s for pg_dump to run.
> It takes about that on my machine too ... with --enable-cassert.
> oprofile said that 90% of the runtime was going into AllocSetCheck,
> so I rebuilt without cassert, and the runtime dropped to 16 seconds.
> What were you testing?
Yeah, you're right, that must have been it. That's a big hit, I didn't
realise cassert was so heavy. (Note to self: test with production build
settings). I don't seem to be batting 1000 ...
I still need to get to the bottom of why the client's machine is taking
so long.
I do notice that we seem to be doing a lot of repetitive tasks, e.g.
calling pg_format_type() over and over for the same arguments. Would we
be better off cacheing that?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-10-03 15:40:05 | Re: How can i get record by data block not by sql? |
Previous Message | Alvaro Herrera | 2011-10-03 15:38:27 | Re: pg_dump issues |