Gregory Stark wrote: > "Simon Riggs" <simon@xxxxxxxxxxxxxxx> writes: > > > It's a good idea, but it will require more complex code. I prefer the > > simpler solution of using more processes to solve the I/O problem. > > Huh, I forgot about that idea. Ironically that was what I suggested when > Heikki described the problem. > > I think it's more complex than using posix_fadvise. But it's also more > ambitious. It would allow us to use not only the full random access i/o > bandwidth but also allow us to use more cpu. In cases where the database fits > entirely in ram and we're recovering many many operations modifying the same > blocks over and over that might help a lot. Actually, if you are modifying the same blocks over and over it will help *less*, because applying each record needs to occur only after the previous records that modify the same block have been applied. So you have two possibilities: you skip that record and try to apply the next one, hoping that that record applies to a block that's not locked, (which means you have to remember the skipped record and apply it sometime in the future), or you put the process to sleep until the lock has been released. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "La conclusión que podemos sacar de esos estudios es que no podemos sacar ninguna conclusión de ellos" (Tanenbaum) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
