From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Drastic performance loss in assert-enabled build in HEAD |
Date: | 2013-03-26 21:46:11 |
Message-ID: | 1364334371.353.YahooMailNeo@web162906.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-26 21:47:30 | Re: Ignore invalid indexes in pg_dump |
Previous Message | Tom Lane | 2013-03-26 21:43:54 | pgsql: Ignore invalid indexes in pg_dump. |