Le 2013-07-27 07:04, Marc Delisle a écrit :

> Le 2013-07-27 07:02, Madhura Jayaratne a écrit :
>>
>>
>>
>> On Thu, Jul 25, 2013 at 1:39 AM, Marc Delisle <marc@infomarc.info
>> <mailto:marc@infomarc.info>> wrote:
>>
>>      Le 2013-06-12 17:04, Marc Delisle a écrit :
>>       > Le 2013-06-12 03:23, Michal Čihař a écrit :
>>       >> Hi
>>       >>
>>       >> Dne Tue, 11 Jun 2013 13:20:44 -0400
>>       >> Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>>
>>      napsal(a):
>>       >>
>>       >>> I don't find a winning solution so I'm seeking for advice. In
>>      this bug
>>       >>> report [0], we see that it's annoying to have incorrect page
>>      navigation
>>       >>> (page selector and arrows) for InnoDB.
>>       >>>
>>       >>> However, when I apply my proposed patch (which forces an exact
>>      count in
>>       >>> sql.php), I see delays for larger InnoDB tables.
>>       >>>
>>       >>> For example, on MySQL 5.5.31, the first time I browse a table
>>      having one
>>       >>> million rows, I wait for 9 seconds. I tried with 0.5 million
>>      and it was
>>       >>> about 5 seconds. A few minutes afterwards, even after closing the
>>       >>> browser, my big table starts to display in two seconds.
>>       >>>
>>       >>> I tend to find these delays acceptable and I propose to apply
>>      my patch.
>>       >>
>>       >> I agree this is acceptable and agree with the patch for 4.0.4.
>>       >>
>>       >> For 4.1 I'd go even further - drop MaxExactCount and use only
>>      not exact
>>       >> counts on overview pages and count properly when browsing.
>>       >
>>       > Thanks, I'll have a look at this suggestion for 4.1.
>>       >
>>       >
>>
>>      Hmmm, I think we have a problem with exact counting, see
>>      https://sourceforge.net/p/phpmyadmin/bugs/4027/
>>
>>      It's true that 750 M rows is a lot of rows...
>>
>> Would it make things too slow to get the rough count first and then get
>> the exact count if the rough counts is less than some defined threshold?

(The title of bug #4027 is "$cfg['MaxExactCount'] is ignored when
BROWSING is back")

>
> That's exactly the goal of the MaxExactCount configuration directive,
> and I think it could be applied here as well.
>
> Would not be too slow, as the rough count is very quick.
>