Hi,
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.
[0] https://sourceforge.net/p/phpmyadmin/bugs/3976/
Hi
Dne Tue, 11 Jun 2013 13:20:44 -0400 Marc Delisle 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.
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 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.
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 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...
On Thu, Jul 25, 2013 at 1:39 AM, Marc Delisle 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 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?
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.
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.
On Sat, Jul 27, 2013 at 4:36 PM, Marc Delisle marc@infomarc.info wrote:
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 closingthe
>>> 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.
My bad.
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.
Le 2013-07-27 07:25, Madhura Jayaratne a écrit :
On Sat, Jul 27, 2013 at 4:36 PM, Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info> wrote:
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> >> <mailto: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> <mailto: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. >My bad.
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.
Not necessarily. You see, the guy reporting bug #4027 was aware of this directive and can set it to an appropriate value.
In version 3.0.0 we had 20000 as a default value, not sure why we set it to 0 later.
Le 2013-07-27 08:20, Marc Delisle a écrit :
Le 2013-07-27 07:25, Madhura Jayaratne a écrit :
On Sat, Jul 27, 2013 at 4:36 PM, Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info> wrote:
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> >> <mailto: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> <mailto: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. >My bad.
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.
Not necessarily. You see, the guy reporting bug #4027 was aware of this directive and can set it to an appropriate value.
In version 3.0.0 we had 20000 as a default value, not sure why we set it to 0 later.
See the discussion in https://github.com/phpmyadmin/phpmyadmin/pull/83
but this was before my change in 4.0.4.
-
Madhura Jayaratne -
Marc Delisle -
Michal Čihař