Re: atrocious update performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: atrocious update performance
Дата
Msg-id 26451.1079546289@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: atrocious update performance  ("Rosser Schwarz" <rschwarz@totalcardinc.com>)
Ответы Re: atrocious update performance
Список pgsql-performance
"Rosser Schwarz" <rschwarz@totalcardinc.com> writes:
>> Could you retry the strace with -r and -T options

> Unlike the previous run (this is a trace of the explain), this one went
> immediately.  No delay.

Hm.  It looks like you mistakenly traced psql rather than the backend,
but since the delay went away we wouldn't have learned anything anyhow.
Have you got any idea what conditions may have changed between seeing
delay and not seeing delay?

> I also have, per Aaron's request, a trace -ct against the backend running
> the explain analyze.  I killed it well before "a few minutes"; it's just
> shy of 900K.  I don't think I'll be forwarding that on to the list, though
> I can put it up on a web server somewhere easily enough.
> Try <http://www.totalcardinc.com/pg/postmaster.trace>.

This is pretty odd too.  It looks like it's doing checkpoints every so
often (look for the writes to pg_control), which a backend engaged in
a long-running query surely ought not be doing.  Need to think about
why that might be...

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Rosser Schwarz"
Дата:
Сообщение: Re: atrocious update performance
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: rapid degradation after postmaster restart