I'm running assets2, connecting to some S3 buckets. At the moment we're transitioning between one set of buckets and another, so I would expect our index to be twice as big as it will eventually be. But recent dumps of the database seem to be growing exponentially (it leapt from 10.4Mb to 40Mb in a week and there's an editorial team of one working on the build!) and I think it's the assets_index_data table - a snapshot this morning tells me that it has 3,045,452 rows.

I'd be surprised if we had 10,000 images in these collective buckets, so I can't figure out why that table is so gargantuan - surely it can't be right? It contains big groups of rows that all have the same session id - it's almost as if every time it indexes the buckets, it creates new rows rather than updating existing ones, leading to an enormously bloated table.

Of course I may be completely wrong and perhaps it needs to be this big, but it doesn't seem right and can't continue to grow this way!


Assets does add new rows every time you run indexing. Assets also should be deleting the rows belonging to the current session once it's done indexing (if it's allowed to run to the end).

Either way, it's completely safe to truncate that table, unless you are in the middle of running an index update.

  • Thanks Andris - I'll ask the P&T team to see if there's anything we can do about this. It might be that the index never completes successfully, and that's why it's not working as intended. Feb 18 '14 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.