On Thu, 2007-12-13 at 10:18 -0300, Alvaro Herrera wrote: > 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. Ah, OK, I can see we're on the same lines of thought there. Just posted a reply to Heikki about this sort of idea. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
