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?
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.