Port update outdated problem.

[Clemens Lang]

Hi,

----- On 20 Nov, 2014, at 09:53, René J.V. Bertin rjvbertin at gmail.com wrote:

> Are you saying that for each file, you first look up the port again and again,
> which is probably an operation of a certain cost too?

No, we're not doing that manually. We're just sending a database query with two
statements in the WHERE clause, one of which is a match on the port ID, and one
of which is a file name.

In a way what happens is that we tell SQLite "hey, do this thing for me, and I
don't really care how you get it done quickly". However, SQLite's method to find
a quick plan has changed in a way that the search is no longer quick (searching
for the filename first using an index, which would return a single row only),
but slow (searching for the id first, which returns thousands of rows, and then
scanning these rows for the filename one by one without index).

So what I've done on trunk is restoring the old behaviour by forcing SQLite to
use the index we want it to use, rather than relying on its autodetection.


> What is the point of all those scans, if I may ask?

We're not the ones doing them, SQLite is. We don't really care how SQLite does
things, as long as it's fast.


> I wonder if this also explains the memory exhaustion problems I've seen occur
> during lengthy port upgrades (i.e. many ports at once).

That's very unlikely. I also haven't seen any problems like these.

-- 
Clemens Lang