On 10/03/2011 12:47 AM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
