Tom Lane <t...@sss.pgh.pa.us> wrote: > Using HEAD's pg_dump, I see "pg_dump -s regression" taking 5 > seconds. > On the other hand, running the same executable against the regression > database on a 9.2 postmaster takes 1.2 seconds. Looks to me like we > broke something performance-wise. > > A quick check with oprofile says it's all AllocSetCheck's fault: > > samples % image name symbol name > 87777 83.6059 postgres AllocSetCheck > 1140 1.0858 postgres base_yyparse > 918 0.8744 postgres AllocSetAlloc > 778 0.7410 postgres SearchCatCache > 406 0.3867 postgres pg_strtok > 394 0.3753 postgres hash_search_with_hash_value > 387 0.3686 postgres core_yylex > 373 0.3553 postgres MemoryContextCheck > 256 0.2438 postgres nocachegetattr > 231 0.2200 postgres ScanKeywordLookup > 207 0.1972 postgres palloc > > So maybe I'm nuts to care about the performance of an assert-enabled > backend, but I don't really find a 4X runtime degradation acceptable, > even for development work. Does anyone want to fess up to having caused > this, or do I need to start tracking down what changed?
I checked master HEAD for a dump of regression and got about 4 seconds. I checked right after my initial push of matview code and got 2.5 seconds. I checked just before that and got 1 second. There was some additional pg_dump work for matviews after the initial push which may or may not account for the rest of the time. Investigating now. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
