| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kenneth Marshall <ktm(at)rice(dot)edu> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: 8.4 COPY performance regression on Solaris |
| Date: | 2009-06-19 14:38:52 |
| Message-ID: | 6051.1245422332@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Kenneth Marshall <ktm(at)rice(dot)edu> writes:
> Looking at the XLogInsert() from 8.3 and 8.4, the 8.4
> version includes a call to RecoveryInProgress() at
> the top as well as a call to TRACE_POSTGRESQL_XLOG_INSERT().
> Could either of those have caused a context switch or
> cache flush resulting in worse performance.
Hmm. TRACE_POSTGRESQL_XLOG_INSERT() should be a no-op (or at least,
none of the complainants have admitted to building with --enable-dtrace).
RecoveryInProgress() should be just a quick test of a local boolean,
so it's hard to believe that it costs anything noticeable; but if anyone
who is able to reproduce the problem wants to test this theory, try
taking out these lines
/* cross-check on whether we should be here or not */
if (RecoveryInProgress())
elog(FATAL, "cannot make new WAL entries during recovery");
which are only a sanity check anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2009-06-19 15:20:07 | Re: select max() much slower than select min() |
| Previous Message | Tom Lane | 2009-06-19 14:26:15 | Re: select max() much slower than select min() |