Re: atrocious update performance - Mailing list pgsql-performance

From Tom Lane
Subject Re: atrocious update performance
Date
Msg-id 26451.1079546289@sss.pgh.pa.us
Whole thread Raw
In response to Re: atrocious update performance  ("Rosser Schwarz" <rschwarz@totalcardinc.com>)
Responses Re: atrocious update performance  ("Rosser Schwarz" <rschwarz@totalcardinc.com>)
List 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 by date:

Previous
From: "Rosser Schwarz"
Date:
Subject: Re: atrocious update performance
Next
From: Andrew Sullivan
Date:
Subject: Re: rapid degradation after postmaster restart