Inserts lentos

Hola a todos.
Desde hace un tiempo vengo mejorando la calidad de las consultas que
nuestra aplicación web hace a la DB que administro. Logré bajar muy
exitosamente la carga de nuestro servidor de base de datos a partir de esas
mejoras (reescribiendo SQL, creando índices, etc).
Ahora, a partir de los análisis que hago (ayudado principalmente por la
herrmienta pgfouine), hemos llegado a un punto en que lo que más está
cargando a la base son las acciones de escritura, particularmente los
insert, y más particularmente los insert en una tabla que tiene continuos
inserts y casi nula lectura (es una especie de log). Esta tabla no tiene
foreign keys (ni desde ni hacia ella) ni triggers, es apenas una tabla de
dos columnas por lo que intuyo que no hay más actividad que el propio insert
y nada que se desencadene a partir de él. Es decir, no veo que pueda mejorar
nada desde un "nivel sql": es un insert simple y llano.
Sin embargo, en momentos de mucha actividad (que implican unos 6000 insert
por hora) estos inserts que en condiciones tranquilas demoran, cuanto mucho,
1 milisegundo, pasan a tardar muchos segundos, incluso cerca de 1 minuto.
Por lo que estuve investigando, este comportamiento podría estar relacionado
a la configuración de los segmentos de WAL. Más aún considerando que usamos
PG 8.1.8 y por lo que vi, desde la 8.3 existe una forma de manejar en forma
más distribuida en el tiempo las escrituras con el "background writer
process".
Hasta aquí son sólo conjeturas, me gustaría conocer la opinión de ustedes.
Seguramente migrar a 8.3 sea muy importante, seguramente lo haré pronto,
pero aún así, insisto, me gustaría conocer la opinión de esta lista.
Les copio un par de variables de nuestra configuración, si hay algo que les
interese y no haya copiado, avisenme (hay algunas variables que difieren de
los valores por defecto y suelen tener un comentario encabezado con "EH:").
Por último, un ejemplo del insert del que estuve hablando:
INSERT INTO usr_view_log (visitor_usr, visited_usr, view_time_stamp,
site_id)VALUES (null, 871, now(), 3);
Muchas gracias.

-----------

fsync = on # turns forced synchronization on or
off
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_buffers = 8 # min 4, 8KB each
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000

# - Checkpoints -

#checkpoint_segments = 3 # in logfile segments, min 1, 16MB
each
#checkpoint_timeout = 300 # range 30-3600, in seconds
#checkpoint_warning = 30 # in seconds, 0 is off

#este script hace un scp hacia un servidor remoto donde mantenemos una copia
de la db, todo dentro de una red de 1 Gigabit
archive_command = '/var/lib/postgresql/archive-wal.sh %p'

#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------

# - Memory -

#EH: Increase memory available for handling connections
#EH: to 256MB from the default 8MB
shared_buffers = 32768 # min 16 or max_connections*2, 8KB
each
#temp_buffers = 1000 # min 100, 8KB each
#EH: Allow at least 1 prepared statement by connection,
#EH: because we intend to use them intensively
max_prepared_transactions = 1000 # can be 0 or more
# note: increasing max_prepared_transactions costs ~600 bytes of shared
memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
#EH: Increase work memory used to solve a query from the default
#EH: 1MB to 2MB, allowing for more complex queries to be solved
#EH: in memory without resorting to disk
work_mem = 2048 # min 64, size in KB
#EH: Allow more memory to be used for VACUUMing (default 16MB)
maintenance_work_mem = 32768 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB

# - Free Space Map -

#EH: track free space for more than 1000 tables (default)
#EH: allows us to have more than one copy of the db for
#EH: maintenance purposes
max_fsm_pages = 200000 # min max_fsm_relations*16, 6 bytes
each
max_fsm_relations = 2000 # min 100, ~70 bytes each

# - Kernel Resource Usage -

#max_files_per_process = 1000 # min 25
#preload_libraries = ''

# - Cost-Based Vacuum Delay -

#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits

# - Background writer -

#bgwriter_delay = 200 # 10-10000 milliseconds between
rounds
#bgwriter_lru_percent = 1.0 # 0-100% of LRU buffers
scanned/round
#bgwriter_lru_maxpages = 5 # 0-1000 buffers max written/round
#bgwriter_all_percent = 0.333 # 0-100% of all buffers
scanned/round
#bgwriter_all_maxpages = 5 # 0-1000 buffers max written/round