do you think that still stands, I would like to move it into to the track_index
2009-09-03 24634, 2009
luks
yes, the search servers are overloaded, the database server is not
2009-09-03 24647, 2009
luks
I think track_index is large enough already
2009-09-03 24605, 2009
luks
but you should wait for ruaok
2009-09-03 24616, 2009
ijabz
Yeah sure, I didnt think should be done as part of the search rewite anyway, but thought could possibly go into NGS release
2009-09-03 24609, 2009
luks
I think there is enough PUIDs to double the size of the track index
2009-09-03 24635, 2009
ijabz
II'll need to run a performance test without/without puids to see how they impact a track search
2009-09-03 24635, 2009
luks
how does it affect PUID lookup is also an important test
2009-09-03 24658, 2009
luks
it's the most often used code in MB, as the comment in the source code says
2009-09-03 24643, 2009
ijabz
where do you mean ?
2009-09-03 24609, 2009
luks
how fast are DB-based vs Lucene-based PUID lookups
2009-09-03 24649, 2009
MBChatLogger
luks probably meant ' PUID lookups are what generates the most http hits to musicbrainz.org '
2009-09-03 24649, 2009
luks
PUID lookups are what generates the most http hits to mb.org
2009-09-03 24652, 2009
ijabz is confused
2009-09-03 24625, 2009
ijabz
only talking about finding track by puid, not looking up an individual puid
2009-09-03 24650, 2009
luks
yes, that's why I'm talking about, too
2009-09-03 24606, 2009
luks
what
2009-09-03 24625, 2009
ijabz
ok,, yes would want search over lucene to as quick as search by database, thats harder to measure because you would be interested in this test with production setup which would be more difficult to test
2009-09-03 24621, 2009
ijabz
But my first test would at least indicate if adding puid to track index had much of a negative effect on the track indexing as a whole
2009-09-03 24603, 2009
luks
you can't correctly measure that
2009-09-03 24652, 2009
luks
if you have twice as much data in the index, and maybe 10 as many requests, the disk will have to seek around the disk much more often
2009-09-03 24600, 2009
luks
which will cause regular track searches to be slower
