10

I used the following query Close votes per tag in the glory days of the close vote queue.

During the fuzzying I used the query to keep a sense of the actual number of questions with a close vote in the queue.

Under the new regime I expected the outcome of my query to be close to the actual number of questions in the queue.

However with around 7500 questions in the queue the first 5 tags already overflow that number.

tag       | count
------------------
php       | 4385
javascript| 4347
jquery    | 3136
java      | 2995
c#        | 2469

Tim already commented that I used the wrong table and should use PendingFlags instead which gives me this query.

That outcome shows the correct 5 top tags (javascript, php, java, jquery and html) but the numbers are still way off.

I already tried leaving out FlagTypeId 13 but that is not the whole story.

How should I adapt my query to have a result that is more closely related to the actual number of questions in the queue?

I'm also open for an explanation what data is missing from SEDE to get the actual number.

I'm aware that SEDE data can be 7 days old but at the time of posting SEDE was updated 7 hours ago...

  • Close votes are in the PendingFlags table now, for starters. – Tim Stone May 18 '14 at 14:13
  • @TimStone That improved in the sense that the top tags now match the tags shown on /review but the count is still off. – rene May 18 '14 at 15:04
  • @rene the SEDE always lags behind. Its running off of (up to) a week old, sanitized version of the data - not production. – user213963 May 18 '14 at 16:39
  • Well, you do have to account for the dequeueing of questions, which would be the time factor on a question... also, a question might be tagged more than one thing, so that would account for some of it. – hichris123 May 18 '14 at 17:52
  • @hichris123 does that mean the dequeing is not reflected in the database? It could be possible but I find that hard to believe. Your point on the multiple tags is something I look into... – rene May 18 '14 at 18:28
  • @rene I don't think dequeuing would be reflected in the database, because right now you're using the PendingFlags table. The way that table works is 1) it stores all flags-to-close. Those never age, so they stay around for forever. Also, votes to close are stored in that table, and those do age away, but I'm not sure if they stay in that table forever or what. However, for both of those: ageing != dequeing. If something is dequeued, it doesn't mean all the votes are aged away. – hichris123 May 18 '14 at 18:33

You must log in to answer this question.

Browse other questions tagged .