Comment 13 for bug 635834

(In reply to comment #11)
> Cat(1) measurements help, but as I tried to point out, this is a database,
> and databases have different needs and different I/O patterns than
> cat(1) does. And any solution (once the problem is characterized) will likely
> be rather different too.
>
> You are hardly a typical user, most of whom have no idea
> what callgrind is or does, or what an I/O stall issue is. Please
> stop pretending that you are "just a user" with a stop watch. ;-)

It's not about pretending - its about having many other tasks in my hands...

> (aside)
> Note that there has been a historical issue with Berkeley DB db-4.1.x
> (iirc, been years) with I/O stalls and waits. The issue was tied to
> select vs poll behavior. There's a bugzilla report and a perl script
> reproducer generating 5000 records in Berkeley DB on (iirc) approx a RHEL4 time
> frame.
>
> Which is why I ask for details like
> Can you document I/O stalls & waits as part of a performance problem?

Which I could do only with local recompilation with a special debug hinting.
I've simply thought that package developers have better idea where the problem can be burred.

Is this behavior (from comment 1) similar with rpm5 or is this onlt rpm 4.X thing ?

> Not also that I have never heard or seen an issue with rpmdb performance
> degradation over time until now. Which means that something (other than
> RPM and Berkeley DB which haven't changed much at all) is likely
> relevant to what you are seeing.

Maybe users do not bother to report :)?
Maybe they consider those 12 seconds query time still acceptable?

But as I said - I've tested it on several machines and experienced approximately same results.

I should probably note that my machine is F8 installation continuously upgraded and usually its quite fresh Rawhide. In the past I've been forced to run --rebuilddb just once after some serious problem. So maybe during the live cycle of Fedora release the database stays 'fast' enough?