Jim C. Nasby wrote: > Now that I've got a little better idea of what this code does, I've > noticed something interesting... this issue is happening on an 8-way > machine, and NUM_SLRU_BUFFERS is currently defined at 8. Doesn't this > greatly increase the odds of buffer conflicts? Bug aside, would it be > better to set NUM_SLRU_BUFFERS higher for a larger number of CPUs?
We had talked about increasing NUM_SLRU_BUFFERS depending on shared_buffers, but it didn't get done. Something to consider for 8.2 though. I think you could have better performance by increasing that setting, while at the same time dimishing the possibility that the race condition appears. I think you should also consider increasing PGPROC_MAX_CACHED_SUBXIDS (src/include/storage/proc.h), because that should decrease the chance that the subtrans area needs to be scanned. By how much, however, I wouldn't know -- it depends on the number of subtransactions you typically have; I guess you could activate the measuring code in procarray.c to get a figure. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 www.google.com: interfaz de línea de comando para la web. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
