Re: atrocious update performance

while you weren't looking, Tom Lane wrote:

> 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?

None, offhand. I have noticed that when a large query is running,
the machine can sporadically just freeze--or at least take inordinately
long for some other process, be it top or ls, another query, or whatever
to start. Nothing looks saturated when it happens, and, while you can
count on it to happen, it's not consistent enough to reproduce.

> 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...

Does the fact that all the reads and writes are 32K mean anything out
of the ordinary? $PGSRC/src/include/pg_config_manual.h has BLCKSZ
#defined to 16384. I was running previously with a 32K BLCKSZ, but
that turned out to be rather sub-optimal for as heavily indexed as our
tables are. I've dumped and rebuilt several times since then.

/rls

--
Rosser Schwarz
Total Card, Inc.