MySQL On ipv6

2009-11-29 Thread pramod tk 
Hi,

I want to know whether MySQL Server runs on ipv6 machine. ie. When you start
the MySQL Server it always binds to 127.0.0.1 ipaddress. IS there any way to
bind MySQL Server to IPv6 loopback address [::1].

if i start MySQL Server on pure ipv6 machine which doesnt support
127.0.0.1(ipv4 loopback address) it doesnt start.

Thanks in advance.
Regards,
Pramod TK

[OT} How to pronounce GIF (was: Re: How to pronounce MyISAM and InnoDB)

2007-01-07 Thread TK 
At 10:15 AM 1/7/2007 -0800, Brian Dunning wrote:
My friend says my sam and in-NOD-b. I want to kill him every  
time. He also says jif instead of gif.

The GIF Pronunciation Page:
http://www.olsenhome.com/gif/

In short, the original inventors of the GIF format (CompuServe, 1987) have 
always defined the pronunciation to be like JIF.  So, that has always been 
the correct pronunciation.

- TK

On Jan 7, 2007, at 7:16 AM, Michael Stearne wrote:

I just say

My, I,  Sam and inno, d, b

From: js  [EMAIL PROTECTED]

Sorry for this silly question but I've been always had trouble
pronouncing MyISAM and InnoDB.


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: Undelete a droped table

2006-11-07 Thread TK 

On 11/7/06, Eric Lommatsch [EMAIL PROTECTED] wrote:
I have accidently droped a table from one of my database's. The table was
an innodb table. Is there anyway that I can recover the table or is that
information gone for good if I don't have a current backup of that table?

At 11:09 PM 11/7/2006 +0200, Panos Tsapralis wrote:
so, your only hope is to have a rather fresh backup of your database.

You don't have to worry too much about backup freshness if you also have 
logging enabled.  Then you can always recover the database (or just one table) 
by reverting to the state in the backup, and then applying the commands in the 
log file up to right before the undesired statement.

I performed such a recovery once by hand (after accidentally leaving the WHERE 
off of an UPDATE), and it worked perfectly.  There is at least one (free) tool 
that will do this automatically, too.

- TK




-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Slow query log: administrator command: quit ?

2006-07-31 Thread TK 
My MySQL server (4.0.20, Linux) was running slowly.  I checked the slow queries 
log, and found many of these during the problem period:

# Time: 060730 20:44:40
# [EMAIL PROTECTED]: xxx []
# Query_time: 68  Lock_time: 0  Rows_sent: 0  Rows_examined: 2
# administrator command: Quit;
# [EMAIL PROTECTED]: xxx []
# Query_time: 67  Lock_time: 0  Rows_sent: 0  Rows_examined: 0
# administrator command: Quit;
# [EMAIL PROTECTED]: xxx []
# Query_time: 67  Lock_time: 0  Rows_sent: 1  Rows_examined: 0
# administrator command: Quit;

Any idea what these administrator commands refer to?  What would be trying to 
quit, and why would it be taking 67 seconds?

Thanks in advance for any help,

TK


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Slow query: Getting first initials from an entire table's data

2004-06-12 Thread TK 
I'm still trying to come up with an efficient way to query my table of names for all 
first initials.  Seems to have stumped everyone.

I.e. There are 50,000 names, and I want the final result to be:
A, B, C, F, H, I, J, K...
That is, a list of all first initials that are actually present in the data (and 
ideally are also used in a joined table).

I haven't been able to think of a way to do this efficiently.  My current query looks 
like this:
 select DISTINCT UPPER(LEFT(n.Name,1)) as Initial
 from Names n, Things t
 where n.ID = t.ID
 order by Initial desc

Even if I eliminate DISTINCT, or create a single character index on Name, or create a 
whole field that just has the first character of Name, I can't figure out how to get 
MySQL to not have to scan the entire table.  I get an EXPLAIN that looks like this:

+---+--+---+---+-+-+---+---+
| table | type | possible_keys | key   | key_len | ref | rows  | Extra 
|
+---+--+---+---+-+-+---+---+
| n | ALL  | PRIMARY,ID | NULL  |NULL | NULL| 57674 | Using 
temporary; Using filesort   |
| t | ref  | ID | ID |   5 | n.ID | 4 | where used; Using index; 
Distinct |
+---+--+---+---+-+-+---+---+

Is there any way to do this, or an efficient way to query the table 26+ times with a 
list of first initials?

(My actual query examines 166,000 rows and takes 12 seconds to run, all to give me a 
list of most of the alphabet!)

Thanks in advance,

TK


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: Slow query: Getting first initials from an entire table's data

2004-06-12 Thread TK 
At 05:02 PM 6/12/2004 +0200, Harald Fuchs wrote:
Other DBMSs like PostgreSQL grok indexes on functional expressions;
MySQL doesn't.  Thus your only choice seems to be storing the
uppercased initial in a separate column and putting an index on that
column.

As I indicated, I already tried that it had no effect at all.  MySQL still scans the 
whole table, still doesn't use any indexes, and takes forever at it.

Thanks,

TK

In article [EMAIL PROTECTED],
TK [EMAIL PROTECTED] writes:

 I'm still trying to come up with an efficient way to query my table of names for 
 all first initials.  Seems to have stumped everyone.
 I.e. There are 50,000 names, and I want the final result to be:
 A, B, C, F, H, I, J, K...
 That is, a list of all first initials that are actually present in the data (and 
 ideally are also used in a joined table).

 I haven't been able to think of a way to do this efficiently.  My current query 
 looks like this:
  select DISTINCT UPPER(LEFT(n.Name,1)) as Initial
  from Names n, Things t
  where n.ID = t.ID
  order by Initial desc

 Even if I eliminate DISTINCT, or create a single character index on
 Name, or create a whole field that just has the first character of
 Name, I can't figure out how to get MySQL to not have to scan the
 entire table.


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Getting first initials from an entire table's data (Slow query)

2004-05-30 Thread TK 
I'm trying to come up with an efficient way to query my table of names for all first 
initials.

I.e. There are 50,000 names, and I want a result of:
A, B, C, F, H, I, J, K...
That is, a list of all first initials that are actually present in the data (and 
ideally are also used in a joined table).

I haven't been able to think of a way to do this efficiently.  My current query looks 
like this:
 select DISTINCT UPPER(LEFT(n.Name,1)) as Initial
 from Names n, Things t
 where n.ID = t.ID
 order by Initial desc

Even if I eliminate DISTINCT, or create a single character index on Name, or create a 
whole field that just has the first character of Name, I can't figure out how to get 
MySQL to not have to scan the entire table.  I get an EXPLAIN that looks like this:

+---+--+---+---+-+-+---+---+
| table | type | possible_keys | key   | key_len | ref | rows  | Extra 
|
+---+--+---+---+-+-+---+---+
| n | ALL  | PRIMARY,ID | NULL  |NULL | NULL| 57674 | Using 
temporary; Using filesort   |
| t | ref  | ID | ID |   5 | n.ID | 4 | where used; Using index; 
Distinct |
+---+--+---+---+-+-+---+---+

Is there any way to do this, or an efficient way to query the table 26+ times with a 
list of first initials?

(My actual query examines 166,000 rows and takes 12 seconds to run, all to give me a 
list of most of the alphabet!)

Thanks in advance,

TK


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

startup problems with linux

2004-05-12 Thread TK Banks 
The startup script provided with Fedora linux uses the mysqladmin ping command to 
verify that the server is up after the safe_mysqld command has been issued; however, 
once I changed the password for the root account, this no longer works:  it sits there 
and tries this command 10 times on one second intervals and finally declares failure 
for the startup procedure (even though the server is actually up and as happy as can 
be).  I'm sure I could remedy the problem by encoding the mysql root password in the 
/etc/init.d/mysqld file, but this seems sort of stupid.  Should I just nix the ping 
glop?  Or perhaps creating a ping account with no password but no privledges would do 
the trick?
 
 


-
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'

Re: Problem with .NET applications

2004-01-22 Thread tk 
Hello Marco,

 When I'm trying to do an insert I got the following
 error
 Error [07006][MySQL][ODBC 3.51
 Driver][mysqld-4.0.17-nt] Restricted
 data type attribute violation sql-c-numeric

Could you please provide the code you use to do the
insert.

TK

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: FULLTEXT Search and Hyphens

2003-12-31 Thread tk 
Hello, 

Fulltext section of mysql manual: MySQL uses a very
simple parser to split text into words. A word is
any sequence of characters consisting of letters,
digits,  ' , and   _ . Any word that is present
in the stopword list or is just too short is ignored.

Thus a hyphen would be viewed as a non-word character
and kk-4835 would be split in kk and 4835. And since
the default min. word length is 4, kk would not be
index but 4835 would be. For more info:
http://www.mysql.com/doc/en/Fulltext_Search.html

The only way to search for kk-4835 is to do the search
in Boolean mode and put things in quotes - “kk-4835”
So your query would look like this:

 SELECT * FROM ms_items
 where MATCH (it_mnfgID, it_title, it_descrip)
 AGAINST ('”kk-4835”' IN BOOLEAN MODE )

and 

 I want to be able to type in KK-4835, KK4835, or
 even KK 4835)

To be able to search for the variations you described
above I would just parse the search and insert a
hyphen where it is missing and then perform the same
search above.

Hope this helps,
TK


__
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: FULLTEXT Search and Hyphens

2003-12-31 Thread tk 
Sorry about this,

 The only way to search for kk-4835 is to do the
 search
 in Boolean mode and put things in quotes -
 kk-4835
 So your query would look like this:
 
  SELECT * FROM ms_items
  where MATCH (it_mnfgID, it_title, it_descrip)
  AGAINST ('kk-4835' IN BOOLEAN MODE )

Put things in quotes not question marks. 
TK

__
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: fulltext search speed issue with SQL_CALC_FOUND_ROWS

2003-12-15 Thread tk 
Hello,

  Could one not store the total while using the
 index
  and use select FOUND_ROWS() without
  SQL_CALC_FOUND_ROWS to retrieve the total?
 
 Yes, it could.
 It is the optimization that wasn't implemented yet.
 (but it's in the TODO)

Once again, thanks for the response. 
Could you give an estimation (even if rough) of how
soon this optimization will be implemented? 

Thanks,
TK

 Regards,
 Sergei
 
 -- 
__  ___ ___   __
   /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik
 [EMAIL PROTECTED]
  / /|_/ / // /\ \/ /_/ / /__  MySQL AB, Senior
 Software Developer
 /_/  /_/\_, /___/\___\_\___/  Osnabrueck, Germany
___/  www.mysql.com
 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: Production problem porting from PHP to ASP

2003-12-10 Thread tk 
hello,

what about using:

aspx (with c#) - c++ api - mysql (nt) - with win 2003
server (iis 6.0)

the only thing where i'm no sure is the c++ api. can
it be used with c# or will there be a .net framework
version of the api? if this set up is possible i
suspect that it may at least match php-...

regards,
tk




--- Terence [EMAIL PROTECTED] wrote:
 We just developed  and re-wrote applications on PHP
 from a previous ASP
 environment.
 The performance improvement from ASP-ODBC-MySQL to
 PHP-MYSQL ranged
 from 20-50% in some cases, so it's pretty normal to
 expect a much slower
 response.
 
 Also sorry to hear about the decision.
 
 Terence

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: fulltext search speed issue with SQL_CALC_FOUND_ROWS

2003-12-05 Thread tk 
Hello Sergei, Gunnar, and others,

thank you for your quick responses.
One little mystery remains:

Why does one need to read all the row data (with
SQL_CALC_FOUND_ROWS) to get the total number of
results when using a limit? 

When the index is used to find relevant rows and sort
the results, the code certainly must know how many
total results there are. 

Could one not store the total while using the index
and use select FOUND_ROWS() without
SQL_CALC_FOUND_ROWS to retrieve the total?

Thanks and regards,
TK

--- Sergei Golubchik [EMAIL PROTECTED] wrote:
 Hi!
 
 On Dec 04, tk wrote:
  Hello,
  
  Thanks for the response. 
  There is one thing that is not clear however. 
  
  Regardless of whether or not I perform the
 fulltext
  search with or without the SQL_CALC_FOUND_ROWS
  keyword, the results that I get are exactly the
 same. 
  
  Also, the notion of stopping after the limit is
  reached cannot apply in the fulltext search or
  otherwise we would only get the first 10 matches
 but
  not the first 10 most relevant matches. This
 leads
  me to believe that the fulltext search must be
 looking
  at all the rows in both cases since it otherwise
 would
  not find the same first 10 most relevant records.
  Hence the question why there should be a
 difference in
  time.
 
 The difference is that you only need to read 10 rows
 from the disk
 without SQL_CALC_FOUND_ROWS.
 
 With SQL_CALC_FOUND_ROWS MySQL goes on and reads all
 rows, it takes
 time.
 
 Finding relevant rows and sorting is based on index
 only, row data are
 not read.
  
 Regards,
 Sergei


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: fulltext search speed issue with SQL_CALC_FOUND_ROWS

2003-12-04 Thread tk 
Hello,

Thanks for the response. 
There is one thing that is not clear however. 

Regardless of whether or not I perform the fulltext
search with or without the SQL_CALC_FOUND_ROWS
keyword, the results that I get are exactly the same. 

Also, the notion of stopping after the limit is
reached cannot apply in the fulltext search or
otherwise we would only get the first 10 matches but
not the first 10 most relevant matches. This leads
me to believe that the fulltext search must be looking
at all the rows in both cases since it otherwise would
not find the same first 10 most relevant records.
Hence the question why there should be a difference in
time.

Just to check, I also performed a search with a limit
that was greater than the number of rows in my table
and the first 10 records were again the same.

Here are the results:
rows: about 100,000
colums: average of 500 words

--- RUN 1 --- 
test run with SQL_CALC_FOUND_ROWS (pc was rebooted)
---

SELECT SQL_CALC_FOUND_ROWS id
FROM main 
WHERE MATCH (abstract) AGAINST ('access')
LIMIT 0,10

++
| id |
++
|  53957 |
|  21607 |
| 106369 |
|   1916 |
|  50071 |
|  39942 |
|  99764 |
|  99467 |
|  51820 |
|  19956 |
++
10 rows in set (94.16) sec

EXPLAIN SELECT SQL_CALC_FOUND_ROWS id
FROM main 
WHERE MATCH (abstract) AGAINST ('access')
LIMIT 0,10

+---+--+---+--+
| table | type | possible_keys | key  | 
+---+--+---+--+
| main  | fulltext | abstract  | abstract |  
+---+--+---+--+
-++--+-+
 key_len | ref| rows | Extra   |
-++--+-+
   0 ||1 | Using where |
-++--+-+

SELECT SQL_CALC_FOUND_ROWS id
FROM main 
WHERE MATCH (abstract) AGAINST ('access')
LIMIT 0,10;
select FOUND_ROWS()

17501 rows

--- RUN 2 --- 
test run without SQL_CALC_FOUND_ROWS (pc was rebooted)
---

SELECT id
FROM main 
WHERE MATCH (abstract) AGAINST ('access')
LIMIT 0,10

++
| id |
++
|  53957 |
|  21607 |
| 106369 |
|   1916 |
|  50071 |
|  39942 |
|  99764 |
|  99467 |
|  51820 |
|  19956 |
++
10 rows in set (0.11) sec

EXPLAIN SELECT id
FROM main 
WHERE MATCH (abstract) AGAINST ('access')
LIMIT 0,10

+---+--+---+--+
| table | type | possible_keys | key  | 
+---+--+---+--+
| main  | fulltext | abstract  | abstract |  
+---+--+---+--+
-++--+-+
 key_len | ref| rows | Extra   |
-++--+-+
   0 ||1 | Using where |
-++--+-+

--- RUN 3 --- 
test run without SQL_CALC_FOUND_ROWS and with high
limit (pc was rebooted)
---

SELECT id
FROM main
WHERE MATCH (abstract) AGAINST ('access')
limit 10

++
| ppt_id |
++
|  53957 |
|  21607 |
| 106369 |
|   1916 |
|  50071 |
|  39942 |
|  99764 |
|  99467 |
|  51820 |
|  19956 |
... 
17501 rows in set (94.22) sec

EXPLAIN SELECT id
FROM main
WHERE MATCH (abstract) AGAINST ('access')
limit 10

+---+--+---+--+
| table | type | possible_keys | key  | 
+---+--+---+--+
| main  | fulltext | abstract  | abstract |  
+---+--+---+--+
-++--+-+
 key_len | ref| rows | Extra   |
-++--+-+
   0 ||1 | Using where |
-++--+-+

So to summarize the question:

To get the most relavent first 10 results, fulltext
seach must be going through all records with or
without the SQL_CALC_FOUND_ROWS keyword, so why would
there be such a huge difference in time. 

Thanks,
TK


--- Matt W [EMAIL PROTECTED] wrote:
 Hi,
 
 Yes, you would have similar results with any query
 that uses
 SQL_CALC_FOUND_ROWS. That's because MySQL has to see
 how many rows would
 be found without the LIMIT. So in your case, it
 can't just abort the
 query after it finds 10 rows. All rows that match
 the WHERE need to be
 found.
 
 You might want to try your fulltext search IN
 BOOLEAN MODE to see if
 that runs any faster. :-)
 
 
 Hope that helps.
 
 
 Matt
 
 
 - Original Message -
 From: [EMAIL PROTECTED]
 Sent: Thursday, December 04, 2003 9:13 AM
 Subject: fulltext search speed issue with
 SQL_CALC_FOUND_ROWS
 
 
  I have some_table with 100,000 rows and with an
  average of 500 words in some_column of each row.
 When
  i do a fulltext search on this table using a query
  such as the following, all of my results are under
 0.1
  seconds:
 
  SELECT something
  FROM some_table
  WHERE MATCH (some_column) AGAINST
 ('some_search_term')
  LIMIT 0,10
 
  However, when i add the SQL_CALC_FOUND_ROWS
 keyword
  like in the following query, some queries take