Hello,
On Sep/25/2008, Ananda Kumar wrote:
> On the new machine its on a different partition than the database.
>
> Also did u try to analyze the table and run the query
I will do it (maybe on Saturday, as I guess that will take long time to
do it). But I think that I did last weekend when I mo
On the new machine its on a different partition than the database.
Also did u try to analyze the table and run the query
On 9/25/08, Carles Pina i Estany <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> On Sep/25/2008, Ananda Kumar wrote:
> > is /tmpdir parameter on both machines using the default va
Hello,
On Sep/25/2008, Ananda Kumar wrote:
> does it have the same network speed as your old server.
yes, it has. But I'm running the query from localhost :-) (socket
connection). Even, the query only returns one number and I don't have
any federated tables, etc.
>
> On 9/25/08, Carles Pina i
Hello,
On Sep/25/2008, Ananda Kumar wrote:
> is /tmpdir parameter on both machines using the default value
Old machine: yes.
New machine: I have tried two places (different partitions, same FS
-ext3-, same hard disk). On the old machine it's in a different
partition of the same hard disk than t
is /tmpdir parameter on both machines using the default value
On 9/25/08, Carles Pina i Estany <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> On Sep/25/2008, Ananda Kumar wrote:
> > does it have the same network speed as your old server.
>
> yes, it has. But I'm running the query from localhost :-) (
does it have the same network speed as your old server.
On 9/25/08, Carles Pina i Estany <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> On Sep/24/2008, Phil wrote:
> > Just a wild guess but, did you perhaps change the filesystem to a
> > journalling filsystem when moving to the different server?
>
>
Hello,
On Sep/24/2008, Phil wrote:
> Just a wild guess but, did you perhaps change the filesystem to a
> journalling filsystem when moving to the different server?
mount reports the same (ext3)
> I once accidently moved my database from an ext2 to an ext3 partition and it
> took me a while to f
Just a wild guess but, did you perhaps change the filesystem to a
journalling filsystem when moving to the different server?
I once accidently moved my database from an ext2 to an ext3 partition and it
took me a while to figure out the degradation of queries..
Phil
On Wed, Sep 24, 2008 at 6:16 P
Hello,
I have a database with a "big" table: 350 milion of registers. The table
is a Isam table, very simple:
mysql> describe stadistics;
+-+--+--+-+-++
| Field | Type | Null | Key | Default | Extra
|
+-+--
On Nov 27, 2007 10:21 AM, mos <[EMAIL PROTECTED]> wrote:
> At 05:57 PM 11/26/2007, you wrote:
> >The second query might be faster due to caching.
>
> This can be verified by executing:
>
> RESET QUERY CACHE
>
> before executing the second query. This will clear the queries from the cache.
No need
At 05:57 PM 11/26/2007, you wrote:
The second query might be faster due to caching.
This can be verified by executing:
RESET QUERY CACHE
before executing the second query. This will clear the queries from the cache.
Mike
--
MySQL General Mailing List
For list archives: http://lists.mysql.co
The second query might be faster due to caching.
On 11/26/07, Alexander Bespalov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a problem with SELECT speed. The first execution takes up to several
> minutes while the next (with the same statement) takes not more then several
6, 2007 10:03 AM
Subject: SELECT Speed
> Hi,
>
> I have a problem with SELECT speed. The first execution takes up to
several
> minutes while the next (with the same statement) takes not more then
several
> seconds.
>
> The statement example is:
> select nas.nasIpAddress, count(
Hi,
I have a problem with SELECT speed. The first execution takes up to several
minutes while the next (with the same statement) takes not more then several
seconds.
The statement example is:
select nas.nasIpAddress, count(distinct(acct.user_id)), count(*),
sum(acct.acctOutputOctets) from acct
Hi,
I have a problem with SELECT speed. The first execution takes up to
several minutes while the next (with the same statement) takes not more
then several seconds.
The statement example is:
select nas.nasIpAddress, count(distinct(acct.user_id)), count(*),
sum(acct.acctOutputOctets)
from acct
he index. It's almost like MySQL is returning the results from the index
> file and then doing a non-indexed table join to the table data to get the
> Rcd_Id.
>
> Mike
>
>
> > > -Original Message-
> > > From: mos [mailto:[EMAIL PROTECTED]
> &
Rcd_Id.
Mike
> -Original Message-
> From: mos [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 15, 2004 2:40 PM
> To: [EMAIL PROTECTED]
> Subject: Poor Select speed on simple 1 table query
>
> It doesn't get any simpler than this. :)
>
> The Select statement take
Mos,
Personally, I never use like for anything. I would add a fulltext index
myself and call it a day. But that's me.
Donny
> -Original Message-
> From: mos [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 15, 2004 2:40 PM
> To: [EMAIL PROTECTED]
> Subject:
It doesn't get any simpler than this. :)
The Select statement takes way too long to complete.
select rcd_id, company_name from company where company_name like "fra%"
12357 rows fetched (86.08 seconds)
However if it returns just the column value from the index, it is quite fast:
select company_name
Hi All,
If I got one table A_table with many columns, and a second table B_table is
the same but with just primary field and unique field...
How much meaningful is the time difference between these queries?
1. SELECT unique_field FROM A_table WHERE prim_field='val';
2. SELECT unique_field FROM B_t
Lorderon wrote:
Hi All,
If I got one table A_table with many columns, and a second table B_table is
the same but with just primary field and unique field...
How much meaningful is the time difference between these queries?
1. SELECT unique_field FROM A_table WHERE prim_field='val';
2. SELECT uniqu
On Thu, 26 Feb 2004, Lorderon wrote:
> Hi All,
>
> If I got one table A_table with many columns, and a second table B_table is
> the same but with just primary field and unique field...
> How much meaningful is the time difference between these queries?
> 1. SELECT unique_field FROM A_table WHERE
Janusz Krzysztofik wrote:
> ...
> I am trying to optimize MySQL (3.23.49 from Debian stable) setup for
> ASPseek application. I decided to try InnoDB in order to be able
> to update tables while performing time consuming selects.
> After converting all tables to InnoDB I noticed a big difference
>
Hi,
> > > You are not using any indicies, because there aren't any that could be
> > > used in this query.
> > > Try adding an index on (status,deleted)
> >
> > I wonder: how many possible different values would such an index
> > return?
>
> mysql> select distinct status, deleted from urlword;
> +
Martijn Tonies wrote:
>
> Hi,
>
> > You are not using any indicies, because there aren't any that could be
> > used in this query.
> > Try adding an index on (status,deleted)
>
> I wonder: how many possible different values would such an index
> return?
mysql> select distinct status, deleted fr
Hi,
> You are not using any indicies, because there aren't any that could be
> used in this query.
> Try adding an index on (status,deleted)
I wonder: how many possible different values would such an index
return? If this is a (very) low value, won't the index make things
slower (if it's being u
ndex (was: Big difference in MyISAM and InnoDB SELECT
speed)
Marc,
Thank you for your prompt answer.
I run EXPLAIN in both cases and got:
MyISAM (fast):
mysql> explain select url_id from urlword where deleted=0 and status
De : Janusz Krzysztofik [mailto:[EMAIL PROTECTED]
Envoyé : lundi 24 novembre 2003 13:58
A : [EMAIL PROTECTED]
Objet : Big difference in MyISAM and InnoDB SELECT speed
Hello,
I am trying to optimize MySQL (3.23.49 from Debian stable) setup for
ASPseek application. I decided to try InnoDB in order to
evant one).
>
> Have you done an EXPLAIN on your query ?
>
> May be an index on (origin,status,deleted) could help.
>
> Marc.
>
> -Message d'origine-
> De : Janusz Krzysztofik [mailto:[EMAIL PROTECTED]
> Envoyé : lundi 24 novembre 2003 13:58
> A : [E
nvoyé : lundi 24 novembre 2003 13:58
A : [EMAIL PROTECTED]
Objet : Big difference in MyISAM and InnoDB SELECT speed
Hello,
I am trying to optimize MySQL (3.23.49 from Debian stable) setup for
ASPseek application. I decided to try InnoDB in order to be able
to update tables while performing time cons
Hello,
I am trying to optimize MySQL (3.23.49 from Debian stable) setup for
ASPseek application. I decided to try InnoDB in order to be able
to update tables while performing time consuming selects.
After converting all tables to InnoDB I noticed a big difference
in processing speed of one of the
Hey, you know what? You're right! I'm an idiot.
Thanks. :)
BD wrote:
> Gabriel,
> I have a sneaky suspicion your primary key is a CHAR or
> VARCHAR, right? If so, your select statement is using an integer which
> means it has to convert it for each record. If you put quotes around
>
Gabriel,
I have a sneaky suspicion your primary key is a CHAR or VARCHAR,
right? If so, your select statement is using an integer which means it has
to convert it for each record. If you put quotes around the "30460203" it
will run faster as in:
select IndexField1,Field1,Field2 from t
key_buffer is 384M, table1.MYI is 17.5MB.
Jeremy Zawodny wrote:
>On Mon, Mar 18, 2002 at 11:39:09AM -0500, Gabriel Ricard wrote:
>
>>Greetings,
>>
>>We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large
>>table ( 200,000+ records, 120+ columns) and some simple queries on that
>
On Mon, Mar 18, 2002 at 11:39:09AM -0500, Gabriel Ricard wrote:
> Greetings,
>
> We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large
> table ( 200,000+ records, 120+ columns) and some simple queries on that
> table have pretty inconsistent performance. Due to licensing issues
At 10:39 AM 3/18/2002, you wrote:
>Greetings,
>
>We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large
>table ( 200,000+ records, 120+ columns) and some simple queries on that
>table have pretty inconsistent performance. Due to licensing issues I
>can't give an actual example of
Greetings,
We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large
table ( 200,000+ records, 120+ columns) and some simple queries on that
table have pretty inconsistent performance. Due to licensing issues I
can't give an actual example of the table, but here is an equivalent
exa
37 matches
Mail list logo
