#3976 (ok 4.0.4) Number of Pages

[poiuty]

Poor counts the number of pages in the table.
Sometimes it does not show the last page, even though they are.
Often shows more pages than it actually is.

for example
http://poiuty.ru/img/c221da3eca4c3ef2e0785056f1c3.png

[Marc Delisle]

This happens for an innodb table, correct?

[poiuty]

yes

[Victor Benincasa]

Same problem here, just with InnoDB. Maybe the paging is using something imprecise like "show table status" to count the table rows, don't?

[poiuty]

Maybe for InnoDB SHOW TABLE STATUS
change to
SELECT COUNT(*) FROM t

[Marc Delisle]

@poiuty: we know of this possibility but have always been reluctant of using it because of performance issues. See our FAQ 3.11 (reading this FAQ entry, I am tempted to close this bug ticket).

[poiuty]

thx, its work

[Victor Benincasa]

I think it's a bug and should be fixed as it affects directly the navigation feature.

It's ok to use the quick row count on the database structure view, but not at the table view, which should never be expected an incorrect navigation behavior.

[Marc Delisle]

This patch seems to fix the problem, please confirm. I am not yet 100% sure about applying it, however.

diff --git a/sql.php b/sql.php
index 6b41fca..cfe8dea 100644
--- a/sql.php
+++ b/sql.php
@@ -773,7 +773,11 @@ if (isset($GLOBALS['show_as_php']) || ! empty($GLOBALS['validatequery'])) {
) {
// "j u s t b r o w s i n g"
$justBrowsing = true;
- $unlim_num_rows = PMA_Table::countRecords($db, $table);
+ $unlim_num_rows = PMA_Table::countRecords(
+ $db,
+ $table,
+ $force_exact = true
+ );

     } else { // n o t   " j u s t   b r o w s i n g "

[poiuty]

Yes. With patch - shows the number of pages correctly

Without the patch.
http://poiuty.ru/img/37e8edd38314b8d1b9f8cd7e0682.png

With the patch.
http://poiuty.ru/img/f7c4a713872adf81eddb175c0ad7.png

Thx.

[Victor Benincasa]

This patch works as expected here. Thanks Marc.

[Marc Delisle]

Well, I started a discussion on the phpmyadmin-devel mailing list because for large tables, there are delays. Did you try the patch with tables having many thousands of rows?

[poiuty]

with the patch
Displays a string 0 - 29 ( 14,113,224 total, Query took 0.0001 sec.)
Displays a string 120 - 149 ( 14,113,224 total, Query took 0.0003 sec.)
Displays a string 3960 - 3989 ( 14,113,224 total, Query took 0.0011 sec.)
...
Displays a string 14112900 - 14112929 ( 14,113,224 total, Query took 2.4139 sec.)

without the patch
Displays a string 13252650 - 13252679 (13,259,256 total, Query took 2.3320 sec.)

[poiuty]

And after cache

Displays a string 14101560 - 14101589 ( 14,113,224 total, Query took 0.0001 sec.)

xdebug dump is useful to you?

[Victor Benincasa]

Here:

Showing rows 0 - 29 ( 2,317,200 total, Query took 0.0004 sec)
Showing rows 30 - 59 ( 2,317,187 total, Query took 0.0005 sec)
Showing rows 2317170 - 2317199 ( 2,317,213 total, Query took 1.0107 sec)

[Marc Delisle]

Which MySQL version please?

[poiuty]

5.5 (percona)

[Victor Benincasa]

My config: MySQL 5.5.32 / PMA 4.0.3 (with your patch) / Apache 2 / PHP 5.4 (FastCGI)

[Marc Delisle]

By the way, I'm looking at clock time, not the "Query took x" values.

[Marc Delisle]