Re: 8.4 COPY performance regression on Solaris

От: Tom Lane
Тема: Re: 8.4 COPY performance regression on Solaris
Дата: ,
Msg-id: 6051.1245422332@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: 8.4 COPY performance regression on Solaris  (Kenneth Marshall)
Список: pgsql-performance

Скрыть дерево обсуждения

8.4 COPY performance regression on Solaris  (Alan Li, )
 Re: 8.4 COPY performance regression on Solaris  (Stefan Kaltenbrunner, )
 Re: 8.4 COPY performance regression on Solaris  (Kenneth Marshall, )
  Re: 8.4 COPY performance regression on Solaris  (Tom Lane, )

Kenneth Marshall <> 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


В списке pgsql-performance по дате сообщения:

От: Brian Cox
Дата:
Сообщение: Re: select max() much slower than select min()
От: David Rees
Дата:
Сообщение: Re: select max() much slower than select min()