Re: Optimizing a big query...

At 09:18 AM 3/11/2005, sam wun wrote: mos wrote: At 07:01 PM 3/10/2005, Chris W. Parker wrote: Homam S.A. on Wednesday, March 09, 2005 5:09 PM said: > If your tables are mostly read-only, you could > pre-generate page numbers on a periodic basis and > select only spec

Re: Optimizing a big query...

mos wrote: At 07:01 PM 3/10/2005, Chris W. Parker wrote: Homam S.A. on Wednesday, March 09, 2005 5:09 PM said: > If your tables are mostly read-only, you could > pre-generate page numbers on a periodic basis and > select only specific ranges WHERE row_number BETWEEN >

RE: Optimizing a big query...

At 07:01 PM 3/10/2005, Chris W. Parker wrote: Homam S.A. on Wednesday, March 09, 2005 5:09 PM said: > If your tables are mostly read-only, you could > pre-generate page numbers on a periodic basis and > select only specific ranges WHERE row_number BETWEEN > page_start

RE: Optimizing a big query...

Homam S.A. on Wednesday, March 09, 2005 5:09 PM said: > If your tables are mostly read-only, you could > pre-generate page numbers on a periodic basis and > select only specific ranges WHERE row_number BETWEEN > page_start AND page_finish. How about just getting the

Re: Optimizing a big query...

--- mos <[EMAIL PROTECTED]> wrote: > Correct, but the speed difference will more than > make up for it. If you > have a busy website, it is very important not to > overtax the database > server with frills, like the number of rows found. > If you want to have the > record counts, then you will h

Re: Optimizing a big query...

At 07:19 PM 3/9/2005, you wrote: Unfortunately this doesn't work well if you want to tell your users how many pages were found in the query. Correct, but the speed difference will more than make up for it. If you have a busy website, it is very important not to overtax the database server with fr

Re: Optimizing a big query...

Unfortunately this doesn't work well if you want to tell your users how many pages were found in the query. Sure, you could use SQL_CALC_FOUND_ROWS with FOUND_ROWS(), but this will defeate the purpose of the LIMIT clause -- speed -- because MySQL will have to figure out all the results of the query

Re: Optimizing a big query...

If your tables are mostly read-only, you could pre-generate page numbers on a periodic basis and select only specific ranges WHERE row_number BETWEEN page_start AND page_finish. Or you could just send the top 1000 IDs of the table to the client, and have the client figure out which IDs belong to w

Re: Optimizing a big query...

Carlos, Apart from using the proper indexes, you should only retrieve the number of rows that are going to be displayed on the page at one time. If you are displaying 10 rows on the page, why retrieve 1000 rows? The user would have to page through it 100x and you have to ask yourself, is

Re: Optimizing a big query...

ould do on the client side to > help. > > --Original Message-- > From: Carlos Savoretti > To: MySQL List > Sent: Mar 9, 2005 5:49 PM > Subject: Optimizing a big query... > > Hi all: > > I programming a GUI which retrieve big tables oftenly. > > So, I retrieve chun

Re: Optimizing a big query...

size of the row. I do not know what you could do on the client side to help. --Original Message-- From: Carlos Savoretti To: MySQL List Sent: Mar 9, 2005 5:49 PM Subject: Optimizing a big query... Hi all: I programming a GUI which retrieve big tables oftenly. So, I retrieve chunks of

Optimizing a big query...

Hi all: I programming a GUI which retrieve big tables oftenly. So, I retrieve chunks of 1000 rows and paginate then to browse the entire table. It works fine, but it's rather slow. I would like to know if I could set some option thru mysql_option() to optimize the client side (mysql-client-3.