<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 4:36 PM, Marc Delisle <span dir="ltr"><<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le 2013-07-27 07:04, Marc Delisle a écrit :<br>
<div><div class="h5">> Le 2013-07-27 07:02, Madhura Jayaratne a écrit :<br>
>><br>
>><br>
>><br>
>> On Thu, Jul 25, 2013 at 1:39 AM, Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a><br>
>> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>> wrote:<br>
>><br>
>>      Le 2013-06-12 17:04, Marc Delisle a écrit :<br>
>>       > Le 2013-06-12 03:23, Michal Čihař a écrit :<br>
>>       >> Hi<br>
>>       >><br>
>>       >> Dne Tue, 11 Jun 2013 13:20:44 -0400<br>
>>       >> Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>><br>
>>      napsal(a):<br>
>>       >><br>
>>       >>> I don't find a winning solution so I'm seeking for advice. In<br>
>>      this bug<br>
>>       >>> report [0], we see that it's annoying to have incorrect page<br>
>>      navigation<br>
>>       >>> (page selector and arrows) for InnoDB.<br>
>>       >>><br>
>>       >>> However, when I apply my proposed patch (which forces an exact<br>
>>      count in<br>
>>       >>> sql.php), I see delays for larger InnoDB tables.<br>
>>       >>><br>
>>       >>> For example, on MySQL 5.5.31, the first time I browse a table<br>
>>      having one<br>
>>       >>> million rows, I wait for 9 seconds. I tried with 0.5 million<br>
>>      and it was<br>
>>       >>> about 5 seconds. A few minutes afterwards, even after closing the<br>
>>       >>> browser, my big table starts to display in two seconds.<br>
>>       >>><br>
>>       >>> I tend to find these delays acceptable and I propose to apply<br>
>>      my patch.<br>
>>       >><br>
>>       >> I agree this is acceptable and agree with the patch for 4.0.4.<br>
>>       >><br>
>>       >> For 4.1 I'd go even further - drop MaxExactCount and use only<br>
>>      not exact<br>
>>       >> counts on overview pages and count properly when browsing.<br>
>>       ><br>
>>       > Thanks, I'll have a look at this suggestion for 4.1.<br>
>>       ><br>
>>       ><br>
>><br>
>>      Hmmm, I think we have a problem with exact counting, see<br>
>>      <a href="https://sourceforge.net/p/phpmyadmin/bugs/4027/" target="_blank">https://sourceforge.net/p/phpmyadmin/bugs/4027/</a><br>
>><br>
>>      It's true that 750 M rows is a lot of rows...<br>
>><br>
>> Would it make things too slow to get the rough count first and then get<br>
>> the exact count if the rough counts is less than some defined threshold?<br>
<br>
</div></div>(The title of bug #4027 is "$cfg['MaxExactCount'] is ignored when<br>
BROWSING is back")<br>
<div class=""><div class="h5">><br>
> That's exactly the goal of the MaxExactCount configuration directive,<br>
> and I think it could be applied here as well.<br>
><br>
> Would not be too slow, as the rough count is very quick.<br>
><br></div></div></blockquote><div>My bad.</div><div><br></div><div>So I think it's best to use $cfg['MaxExactCount'] in browsing as well. However IMO, its default value being 0 would break its purpose.</div>
</div><div><br></div>-- <br>Thanks and Regards,<div><br></div><div>Madhura Jayaratne<br><div><br></div></div>
</div></div>