Erik,
> You'er welcome! However, I believe our situation is very different
> from what you're testing if I understand you correctly. Are you
> saying that you're entire database will fit in memory? If so, then
> these are very different situations as there is no way ours could
> ever do that. In fact, I'm not sure that forcedirectio would really
> net you any gain in that situation as the IO service time will be
> basically nil if the filesystem cache doesn't have to page which I
> would think is why your seeing what you are.
Even more interesting. I guess we've been doing too much work with
benchmark workloads, which tend to be smaller databases.
Thing is, there's *always* I/O for a read/write database. If nothing else,
updates have to be synched to disk.
Anyway ... regarding the mystery transactions ... are you certain that it's
not your application? I can imagine that, if your app has a fairly tight
retry interval for database non-response, that I/O sluggishness could
result in commit attempts spinning out of control.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---------------------------(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
