Στις 26-09-2011, ημέρα Δευ, και ώρα 08:47 +0200, ο/η melvin_mm έγραψε: So I'd prefer not to count fromm a bunch of different times and web sites. Here's what I can tell you: Sometime after Sept 1 16:06:24 UTC and before Sept 1 17:24:20 there were 412482641 revisions not deleted, according to the dumps. On Sept 1 at 16:32 there were a total of 447880000 revisions, including deleted revisions. That gives a difference of 35397359 deleted revisions (revisions no longer in the revision table). Some of those are outright deleted, and therefore among the 33000000 or so that landed in the archive table. When a page gets restored it and all the revisions get new ids. the old ids don't point to anything any more, they are unused. I suppose that is true for undeleting selected revisions as well. That is where the missing revisions are going to be. And a small number of revisions are gone completely: see http://en.wikipedia.org/wiki/Wikipedia:Viewing_and_restoring_deleted_pages#… Ariel

On Mon, Sep 26, 2011 at 4:59 PM, Ariel T. Glenn <ariel(a)wikimedia.org> wrote: As you say, there are gaps in the rev_id sequence due to undeleted revisions and possibly the occasional transaction-rollback-induced gap. The real real number would be SELECT COUNT(*) FROM revision; but that'll probably take like half an hour to count all rows. Roan Kattouw (Catrope)

2011/9/26 Platonides <Platonides(a)gmail.com>om>: No. This works for the MAX(), but not for the COUNT(), where it literally has to count row-by-row. Since there are gaps in the revids, MAX(rev_id) > COUNT(*). Roan Kattouw (Catrope)

2011/9/26 Platonides <Platonides(a)gmail.com> Index row counts are approximate (and sometimes *wildly* inaccurate) in InnoDB -- the only way to get an accurate count is to actually go through the whole table (or at least the whole index) and count the entries, which takes time and memory and holds a transaction open while it works. You can get the top or the bottom entry in the index very quickly -- but there simply isn't an accurate count ready to read. (MyISAM tables do store actual counts in the indexes which COUNT(*) can optimize on, but that basically never helps you in practice since we don't like our databases to crash. ;) -- brion

Platonides <Platonides <at> gmail.com> writes: Thanks, this is quite close to the result from September 1st ( 412,482,641 ). I assume that the contents of the "revision" table go into the pages-meta-history dumps..? And I reckon that there is no safe method to verify the result, though. ~~Katja Mueller

On 28 September 2011 16:41, Brion Vibber &lt;brion(a)pobox.com&gt; wrote: SELECT * FROM `revision` LEFT JOIN `page` ON `rev_page` = `page_id` WHERE `page_id` IS NULL Anyone want a sweepstake on how long that'll take? 8-) --HM