optimization proposal -- playlist stored in the DB

[Maximilian Kossick]

On Friday, 6. October 2006 09:41, Ovidiu Gheorghioiu wrote:
> Hi guys,
>
SNIP
>
> I think having the playlist in the DB would eliminate these issues.
> Loading would definitely be faster, as can be seen from the smart
> playlist loading time (1.1%in SqlLoader) -- and the smart playlist is
> actually a fairly complicated query. Saving will likely be much faster
> too, and most importantly it can be done incrementally for things like
> undo or autosave.

I agree.

> And there are other fringe benefits, too. For example, another 6% was
> spend loading song ratings one by one as I was scrolling, on the first
> instance of the playlist which came from XML -- these can probably be
> stored right in the playlist table.

That can be solved relatively easily by not lazy loading the song scores and 
ratings. At the moment, CollectionDB only loads the actual song tags when 
creating a new MetaBundle. It should be possible to add a join on the 
statistics table and read the song score and rating without a performance 
hit. The song scores and ratings are stored in XML when they are available, 
too.

> So, what do you guys think? I'd be willing to do a significant amount
> of the work, but I would likey need / use some help from somebody
> who's familiar with the DB. And also some testing on the other two
> db's, which I don't have installed or configured.

Ask here or (better) in our IRC channel. It should be possible for you to 
stick to standard SQL which works on all supported databases. Somebody will 
usually complain in #amarok within a few minutes of your commit if the SQL is 
broken;)

> Regards,
> Ovy

Cheers, Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061006/6e1c9f0a/attachment.sig>