On Mon, Sep 15, 2014 at 8:43 PM, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
On 2014-09-16 01:29, Claudio Freire wrote:
On Mon, Sep 15, 2014 at 8:25 PM, Carlos E. R.
So it is obvious! We simply run the cp to null thing ahead of the query on the script, and done.
Yes, it's a nice band-aid if the system has enough memory.
Not so much if it doesn't.
True.
It is a hack, or band-aid, as you say. The real problem is how the database engine is coded: it is made, apparently, to minimize ram, doing non-sequential and non-cached disk reads.
That's not the case. It does use cached reads, but it takes about a minute to cache the whole thing in random order, whereas it takes only a few seconds in sequential order. I'm having a hard time following rpmdb.c's code. I see it uses plain db3 cursors, which should be sequentially scanning the file instead of hopping all over the place. If it's truly the case, then it's db3 the one that needs fixing. If it's rpmdb.c creating other cursors in parallel and seeking other parts of the packages database, which I can't rule out because I couldn't fully figure out the code yet, but seems unlikely, it's rpmdb.c the one in need of fixing. I think a simple test case should clear this. I'll try to make one with python (it has a nice and neat interface to db3 that's easier to use than C for this). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org