Re: optemizer for mySQL!

2006-05-15 Thread Alexey Polyakov

Googling for mysql profiler brings a link:
http://amr.activechannel.net/myprofiler.htm
Well... that looks like something really good. I have a question for
all of list subscribers: has anyone use this tool? Does it really do
what it pretends to do?

On 5/15/06, sheeri kritzer [EMAIL PROTECTED] wrote:

I'm not sure what you mean by profiler -- where are you getting your
information from?  It's not referenced in the article I sent.  If you
mean checking to see if indexes are being used during a query, check
out the EXPLAIN syntax.

http://dev.mysql.com/doc/refman/5.0/en/explain.html

-Sheeri

On 5/14/06, Jim [EMAIL PROTECTED] wrote:

 Thanks Sheeri,

 How do you run the profiler and what does it do?
 Have recently had to add some indexes to various tables to improve
 performance so does not seen to be running automatically.



 -Original Message-
 From: sheeri kritzer [mailto:[EMAIL PROTECTED]
 Sent: Saturday, 13 May 2006 2:05 AM
 To: Jim
 Cc: mysql@lists.mysql.com
 Subject: Re: optemizer for mySQL!

 http://www.devshed.com/c/a/MySQL/A-Technical-Tour-of-MySQL/

 The MySQL server has it built in.

 -Sheeri

 On 5/8/06, Jim [EMAIL PROTECTED] wrote:
  Hi All,
 
 
 
  Didn't know there was an optemizer for mySQL.
 
  Where can I get it from?
 
 
 
  Thanks
 
  Jim
 
 
 
 
 
  Best regards,
 
 
 
  Jim Clark
  Project Manager
  Multilink Systems
  Ph: 03 9425 9400
  Fax: 03 9425 9811
 
 
 
 
 


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



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





--
Alexey Polyakov

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



Re: Tuning a Server with 10,000 databases

2006-05-08 Thread Alexey Polyakov

On 5/9/06, Alex [EMAIL PROTECTED] wrote:


That's what I actually did now. We have got the databases start with
usernames + number appended situation here so i patched sql_show.cc
code to only do acl checks on databases starting with the username.

Still not optimal but cuts down a show databases on a server with 60.000
databases from 15 seconds to 0.14 seconds which is ok.


Same here - my database names start with username+underscore, so query
now takes 0.05 instead of 6 secs (I have about 15000 DBs).

--
Alexey Polyakov

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



Re: Tuning a Server with 10,000 databases

2006-05-06 Thread Alexey Polyakov

That's not a bug, that's a missing feature (or we can call it
unoptimal behaviour).

I think that having 1 databases and 1 users on a single mysqld
and doing show databases query often isn't what developers see as
intended usage for MySQL. :)

Here's what happens when you do show databases query:
1) mysqld gets a list of subdirectories of mysql data dir (usually
/var/lib/mysql). Each directory is a database
2) It loops through all entries, and adds an entry to result set if:
 a) an user has global show databases privilege
 b) an user has been granted access for this database
Part b) is what actually takes time. For each entry the server first
checks ACL cache. It's a hash table and lookups against it are very
fast. But for show databases query most lookups will return a miss,
and a miss means full scan of the whole acl db. So for 1 databases
it scans table with 1 rows 1 times, which means 10 million
scanned records. That's why it's slow.
As a workaround, if one has some rules regarding which user can see
which DB (for example, if usernames and database names start with same
substring), they can add this check to the code (so scans will be
avoided for most entries). That's still far from optimal, but at least
show databases will take dozens of milliseconds instead of seconds.

On 5/6/06, sheeri kritzer [EMAIL PROTECTED] wrote:

Perhaps it's time to file a bug report, then?

-Sheeri

On 5/3/06, Alex [EMAIL PROTECTED] wrote:
 This problem is indeed not related to OS / Hardware Problems.

 Take a look at this thread:

 http://lists.mysql.com/mysql/197542

 Read the part about show databases as root vs standard user

 + observed file system activity.



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



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





--
Alexey Polyakov

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



Re: Optimising for many rows and returned records (de-coupling query time to record set size for range queries)

2006-04-23 Thread Alexey Polyakov
On 4/23/06, Nick Hill [EMAIL PROTECTED] wrote:

 1) I can improve performance by a factor of 2-2.5 by changing the double
 lat/lon to an integer then selecting on an integer.

 2) I have concluded that for each 10 fold increase in the number of
 records, select queries take twice as long. For each doubling of the
 number of returned records, there is a sqrt(2) increase in select query
 time.

I've noticed a couple things.
1) Right now you're emulating spatial index.
2) In future, you're going to emulate partitioning.

Why do you think that doing this stuff manually is better than using
builtin capabilities?

 As the database grows, it would likely improve database performance by
 splitting an individual table into several thousand tables using the
 file system directory btree algorithm to effectively pre-select the data
 before the query is handled to the MySQL engine. This is not a neat
 solution. A much better way would be to improve the mysql index
 performance on very large numbers of records.

Selects against a table use b-trees too. Splitting data into lot of
tables won't help with selects at all (well, it may help on scans with
concurrent large data sets if data will be spread across different
physical drives, but not with regular range lookups that you're
doing). It will only help with inserts.

 Given that there is such a strong relationship between the number of
 records returned, and query time, I conclude that the whole index tree
 is matched for every given number of root x records returned. If all
 records we are matching are under a single node or under a small number
 of nodes in the index tree, perhaps there is some way of telling the
 database engine to ignore the rest of the index tree.

What is a 'root record'? Are you speaking about internal
representation of b-tree?

 Could this work, or am I misunderstanding how the index tree works? Are
 there existing optimisations which can de-couple the relationship
 between number of records and query time where the records I am
 selecting are within a small range?

For studying select query performance issues it's better think about
index as simply about a sorted array with random-access, where each
random access costs O(lgN) and accesses to adjanced data cost O(1).
If your points are spread uniformly in space, cost of select query
you've shown is O(N*lgN)


--
Alexey Polyakov

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



Re: Execution time of show databases increases when fewer databasesare visible

2006-04-21 Thread Alexey Polyakov
On 4/21/06, Nico Sabbi [EMAIL PROTECTED] wrote:

 Is this behaviour due to a bug or maybe my mysql tables are messed up?

I'm not sure if we can call it a bug. But spending 8 seconds (and
using 100% CPU) for a simple SHOW DATABASES query is a bit too much,
and should be fixed.

mysqld first reads directories name from its data directory, then
loops over all names and does the following check:

if (thd-master_access  (DB_ACLS | SHOW_DB_ACL) ||
acl_get(thd-host, thd-ip, thd-priv_user, file_name,0) ||
(grant_option  !check_grant_db(thd, file_name)))

If a query runs faster when user has access to more DBs, then the
problem most likely lies within check_grant_db function.

But it all needs more careful investigation.

--
Alexey Polyakov

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



Re: Execution time of show databases increases when fewer databasesare visible

2006-04-21 Thread Alexey Polyakov
On 4/21/06, Nico Sabbi [EMAIL PROTECTED] wrote:

 the more databases a user has the less time it takes to execute show
 databases and vice versa:

If no rows in `show databases` output appear because some user has
some table/columns privs but no db privs for a database in question,
then I think that check_grant_db I mentioned in previous email may be
safely hacked away.

--
Alexey Polyakov

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



Re: newbie optimization question

2006-04-20 Thread Alexey Polyakov
On 4/20/06, Adam Wolff [EMAIL PROTECTED] wrote:

 How can I optimize the case where I filter on one key but sort on another?
 This is fast:
SELECT * FROM contacts WHERE fullname LIKE j% ORDER BY fullname LIMIT 10;

 But this is slow:
SELECT * FROM contacts WHERE fullname LIKE j% ORDER BY email LIMIT 10;

 EXPLAIN tells me that the optimizer is using filesort for the second
 but not the first (which makes sense.)

Such things are pretty hard to optimize. If you have large number of
rows, forcing usage of (email) index for this query might help, as
engine will scan as many rows as required for satisfying limit. Also
having (email, fullname(1)) index might save a few cycles.

 * Question 2:
 Why does introducing an extra WHERE clause make things slower?
 If I do this:
SELECT * FROM contacts WHERE fullname LIKE j% AND user_id=1
ORDER BY fullname LIMIT 10;

Probably because the engine is not using (fullname) index for this
query - optimizer sees 'const' ref for user_id, retrieves all rows
that have user_id=1 and then filters/sorts them all.

--
Alexey Polyakov

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



Re: Insert speed on table with 7M rows but small row size.

2006-04-08 Thread Alexey Polyakov
On 4/8/06, Kevin Burton [EMAIL PROTECTED] wrote:

 Is there anyway I can tune MySQL to improve this operation?

There's a fundamental problem with B-trees - inserts in a big B-tree
can be very slow, cause it may require tree rebalancing.
One workaround for this problem is partitioning. MySQL 5.1 will have
built-in partitioning support, but the idea itself is very simple, and
you can achieve the same effect by manually spreading data among
tables.

--
Alexey Polyakov

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



Re: Tuning a Server with 10,000 databases

2006-04-01 Thread Alexey Polyakov
Hi!
I'm facing somewhat similar problems - I've stuffed about 10 thousand
databases, most of them are pretty small and not very active, and some
of the queries are extremely slow.
I've tried different filesystems, and currently I'm using
bleeding-edge reiser4 filesystem. It handles large directories very
well, commands like `find /var/lib/mysql|wc -l` complete under a
second, but when for example authenticated user does SHOW DATABASES
query, it takes about 15 seconds to complete.
I'm pretty sure it's not OS or filesystem issue, cause during this
query mysqld process consumes all available CPU time in user-land (if
it was FS or OS issue, it would use kernel CPU time).
I've tried pretty much anything I can think of, but can't seem to
solve the problem. Splitting the databases between several mysqld
instances will help of course, but it will be pretty tough to
administer.
I'm going to complile mysqld from sources with profiling enabled, then
gather profiling info, and submit it as a bug. Seems that's the only
thing that may help.

On 4/1/06, Gary Huntress [EMAIL PROTECTED] wrote:
 I have been offering free database hosting for over 4 years and I've
 been doing it on a shoestring.My last MySQL server was a generic
 1GHz system with 256MB RAM running Redhat 9.   The performance was
 surprisingly good because the query loads were not typically high.   One
 persistent problem was the initial connection times.   On that old
 system if I had less than approx 10,000 separate databases then the
 connection times were fast, and on the order of 1 second or so.   If I
 had more than 10,000 databases this dramatically changed the connection
 times to well over 15 seconds or more.

 I always attributed this connection lag to a problem with the filesystem
 and the large number of directories.  The old server had RH9 and ext3
 with no htree support which I was told could help with this problem.

 I recently bought a new 2.4 GHz system with 1GB of RAM and installed
 Fedora 4 with ext3 and htree support.  All new hardware, faster drives,
 more RAM and updated software.  I thought I was golden!Well, I have
 14,000 databases on this new system and it is as slow as the old 1GHz
 system.

 The tuning articles I've read, and the sample my-*.cnf files that ship
 with the tarball appear to apply to the more typical installation of a
 single huge database rather than thousands of individual dbs.   Can
 anyone offer any suggestions?

 Thanks,

 Gary Huntress


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




--
Alexey Polyakov

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



Re: Tuning a Server with 10,000 databases

2006-04-01 Thread Alexey Polyakov
On 4/1/06, Greg Whalin [EMAIL PROTECTED] wrote:

 Not necessarily sure this is the problem.  But if it is, it could be
 solved by switching to a different filesystem.  Or, if you are using
 ext3fs, you could try enabling dir_index on the filesystem (tune2fs -O
 dir_index ... man tune2fs), which could give you a boost in performance
 in a large dir (this could take a long time to complete).  You may also
 want to up your table cache so that mysql can keep more of your commonly
 used tables open?

FWIW, I've experimented heavily with FS options, and found out that
dir_index on ext3 doesn't help at all, it actually harms performance.
'noatime' and 'nodiratime' options do help a little.
Also, 14000 subdirectories is not something that will cause 15 seconds
delay - those 14000 subdirectories will always live in OS dentry cache
anyway.


--
Alexey Polyakov

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



Re: Avoiding disk writes during CREATE TEMPORARY

2006-02-20 Thread Alexey Polyakov
Make sure you don't have dynamic-width rows. Use char instead of varchar.

On 2/17/06, Eamon Daly [EMAIL PROTECTED] wrote:
 Hi, all. I have a machine with lots of memory, and I'm
 trying to avoid the disk entirely for some of our larger
 reports. I was under the impression that CREATE TEMPORARY
 would create in-memory tables and only write to disk if
 tmp_table_size is reached, but that doesn't seem to be the
 case: I've set tmp_table_size to 1G and this particular run
 is only creating tables under 64M. Using TYPE = MEMORY does
 what I want it to and only creates .frm files in /tmp:

 CREATE TEMPORARY TABLE revenue_data TYPE = MEMORY
 SELECT * FROM data

 ...but as we do have reports that might exceed 1G in size,
 and the MEMORY storage type never converts to on-disk
 tables, that's really not a good solution. How does MySQL
 determine whether a table is written to memory or to disk,
 and is there a way to force the former?

 
 Eamon Daly


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




--
Alexey Polyakov

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



Re: MSSQL-MySQL Compatibility Question

2005-10-27 Thread Alexey Polyakov
Yeah, it's perfectly ok to run both on the same machine at the same
time, though with MS SQL you're limited to Microsoft OS.

--
Alexey Polyakov

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



Re: how to increase query speed ?

2005-10-25 Thread Alexey Polyakov
Adding compound (hash, years) index (or even better unique index if it
fits in your business logic)  in both tables should speed up things.

--
Alexey Polyakov

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



Re: Should I buy commercial license?

2005-10-23 Thread Alexey Polyakov
Hi!
There'a a great article about MySQL licensing:
http://entwickler.com/itr/online_artikel/psecom,id,618,nodeid,114.html

Basically, you don't need to purchase license unless you distribute
your software. (And even if you do, it doesn't automatically mean that
you should buy commercial license).

--
Alexey Polyakov

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



Re: Memory tables and INNODB have different query plans for GROUP BY with btree?

2005-10-04 Thread Alexey Polyakov
Hi Kevin, I also observed differences between query plans on InnoDB
and MyISAM tables. I had a complex query, which had two possible
plans, first plan included const and ref joins on bigger tables then
joins on smaller tables, and second one was to do range scan of
smaller table and then join all larger tables. Second plan was 20
times faster, and the only way I managed to force query optimizer to
use range scan is converting tables to InnoDB. (I couldn't use
straight join and force index cause I had no access to scripts that
was generating queries).


Regarding your example, you won't get your index used for group-by if
you're selecting *.
Your select against memory table is using key:TEST to skip sorting of
data (group by means implicit oreder by, and it retrieves row using
this key in already sorted order). When it's in-memory table, random
reads are fast.
Your select against disk table isn't using index cause it's faster to
retrieve all rows by scanning table and then sort them.

If the column you're using for group by was the first part of primary
key in innodb table, it would also use it for retrieval (and that's
the fastest possible way of doing this query on innodb).

On 10/4/05, Kevin Burton [EMAIL PROTECTED] wrote:
 I was benchmarking a few of my queries tonight and I noticed that two
 queries had different query plans based on table type.

 Here's the broken query:

 mysql EXPLAIN SELECT * FROM FOO_LINK_MEMORY_TEST GROUP BY
 TARGET_NODE_ID\G
 *** 1. row ***
id: 1
   select_type: SIMPLE
 table: FOO_LINK_MEMORY_TEST
  type: index
 possible_keys: NULL
   key: TEST
   key_len: 18
   ref: NULL
  rows: 1000
 Extra:
 1 row in set (0.00 sec)

 Note no index is used.


 mysql EXPLAIN SELECT * FROM FOO_LINK_INNODB_TEST GROUP BY
 TARGET_NODE_ID\G
 *** 1. row ***
id: 1
   select_type: SIMPLE
 table: FOO_LINK_INNODB_TEST
  type: index
 possible_keys: NULL
   key: TARGET_NODE_ID
   key_len: 9
   ref: NULL
  rows: 1011
 Extra:
 1 row in set (0.00 sec)

 ...

 and here it uses TARGET_NODE_ID. The only difference is that I
 created an INNODB table and inserted the columns in the memory table
 into the INNODB table.

 I'm trying to follow the instructions here:

 http://dev.mysql.com/doc/mysql/en/loose-index-scan.html

 To get decent GROUP BY performance.  Is this a bug?  Is there a
 workaround?

 Kevin A. Burton, Location - San Francisco, CA
   AIM/YIM - sfburtonator,  Web - http://www.feedblog.org/
 GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04






--
Alexey Polyakov

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



Re: Memory tables and INNODB have different query plans for GROUP BY with btree?

2005-10-04 Thread Alexey Polyakov
Oops, I was obviously wrong about your example, please ignore it. :)

--
Alexey Polyakov

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



Re: config diff: query time went from 70 mins to 20 seconds

2005-10-01 Thread Alexey Polyakov
On 10/1/05, David Sparks [EMAIL PROTECTED] wrote:
 So what was the setting below that was tanking mysql performance?  I
 suspect that innodb_log_buffer_size=32M was the culprit.

I think that tripling your buffer pool did the job. :)
Also I'd revert innodb_additional_mem_pool_size and
innodb_log_buffer_size, cause those are allocated only once, and looks
like you have enough memory for bigger values.

--
Alexey Polyakov

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



Re: Creating HUGE reports

2005-09-25 Thread Alexey Polyakov
I think there are some required indexes missing in your table structure.
If you showed us your real SHOW CREATE TABLE CONTACTS \G and SHOW
CREATE TABLE LISTS \G as well as text of SELECTs that kill your
mysqld, you'd get better replies.
250k/60k records is not that huge tables really.

On 9/25/05, Miguel Cardenas [EMAIL PROTECTED] wrote:
 Hello...

 After solving some problems with the code, now am working with the real one
 database. On my tests was playing with 20,000 records and worked pretty fine
 sorting by X or Y field and setting some 'where ...' conditions.

 At this moment the database has 250,000+ records, new insertions are pretty
 fast, searchs are pretty fast too, but generating reports is almost
 impossible, the computer may hang one hour and still be working with any
 output.

 My tables are something like this:

 CONTACTS - about 250,000 records
 --
 |   id (INT)   |   contact(CHAR)   |   active(BOOL)   |   ...   |
 --

 LISTS - about 60,000 records
 (category for some contacts)
 
 |   id (INT)   |   category(CHAR)   |
 

 Contacts may have a category, although not all of them have one, and some of
 them may be in more than one, so it is not option to use a 'category' field
 inside the CONTACTS table... perhaps, intuitively could have a 'SET' type
 field with categories, but there are not fixed categories and may (will) grow
 with usage...

 There are two conditions that should be both acomplished:


 Cond 1. CONTACTS.active = 1
 Select all active contacts

 Cond 2. LISTS.category = (or ) mycagegory
 Add/remove contacts from the report that are listed in mycategory

 If I try a select on both tables by conditioning CONTACTS.id=LISTS.ID and
 LISTS.category=something the whole system becomes slow and unusable, and
 still do not wait enough to see how long it will take.

 This task will be performed once or twice a week, so it must be optimized, and
 don't know what should be better...

 1st option: let the complex select finish (have no idea of how long will take)

 2nd option: generate a temporal table with results matching Cond1, and then
 apply Cond2 to the temporal table.

 Commonly, the 'category' applies to discard contacts, more than choosing them,
 so I would simply remove LIST.id records from TEMPORAL table where
 LIST.id=TEMPORAL.id and then would have the final report.

 But... what should be better? a single select with complex conditions or a
 temporal table with multiple parses to append/discard records for every
 category used (one or various)?

 Thanks for any comment.


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




--
Alexey Polyakov

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



Re: Bad MySQL performance with LEFT JOINS in combination with BIGINT(16)Keys

2005-09-21 Thread Alexey Polyakov
Looks like you don't have index on `lad_id` field in second table.
So when you do the first query, mysql first does a full scan of 2nd
table, then does eqref lookup for 1st table, which is rather fast
operation. But when you do the left join, it scans first table and for
each value of id does a scan of second table, which is performance
killer.

--
Alexey Polyakov

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



Re: Charset problems (utf-8 - latin1)

2005-09-21 Thread Alexey Polyakov
First, check if actual data in your tables after this conversion is
really properly encoded. Launch your mysql command line client,
execute
SET NAMES latin1;
and do some selects on your table data to see if it's readable.
If it is, then all you need is to make PHP use latin1 when reading
data from db server. One way to do this is to issue 'SET NAMES latin1'
query after establishing a connection. There are also some ways to set
this as global option for all websites if you can't modify scripts.

--
Alexey Polyakov

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



Re: Charset problems (utf-8 - latin1)

2005-09-21 Thread Alexey Polyakov
Also the good way of doing conversion itself is mysqldump table
structure, then import the dump, launch mysql command line utility (or
use phpmyadmin for that) and alter encoding on database and all needed
tables and columns, then mysqldump the first database using utf8
charset (without dropping tables), and import this dump into second
database.

--
Alexey Polyakov

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



Re: bind (listen) question

2005-09-21 Thread Alexey Polyakov
Theres --bind-address mysqld startup option, but I'm afraid it allows
specifying only one IP to bind to.
One of workarounds for your problem is to make it listening on all
IPs, but configure firewall to drop all TCP packets going to port 3306
not on IPs you want.


--
Alexey Polyakov

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



Re: switching from varchar to tinytext

2005-09-04 Thread Alexey Polyakov
Bytes IIRC. Depending on actual content it can be 127-255 characters.
Why do you choose to convert varchar to tinytext? Doesn't look like
good idea to me.

-- 
Alexey Polyakov

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



Re: Blew MySQL away by accident

2005-09-04 Thread Alexey Polyakov
 However, I am trying to move my RH 9 system to Centos 4.1 and
 everything has gone well until I though I could just copy the mysql db
 into the new server.

You can. Just make sure you add old-passwords option to your my.cnf file.

-- 
Alexey Polyakov

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



Re: query-log.html

2005-09-03 Thread Alexey Polyakov
 Trouble is, I dont start mysqld with the --log= option,
 and yet it still insists on logging. How do I disable this?
 (My current method is to use --log=/dev/null but I'm sure
 this cant be the best way). I cant find any evidence of
 a my.cnf anywhere, so I dont think it is due to an unexpected
 config-file option
Add
log=OFF
line to your my.cnf.

-- 
Alexey Polyakov

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



Re: Slow Queries Log and Index-less queries

2005-08-30 Thread Alexey Polyakov
 
 
 I have a question regarding the slow queries log, and queries not using 
 index.
 
 I have a small table, with say 10 entries, like that :
 ID | Element
 -
 1 | One
 2 | Two
 3 | Three
 4 | Four
 5 | Five
 6 | Six
 7 | Seven
 8 | Eight
 9 | Nine
 10 | Ten
 
 I want to get all those entries:
 SELECT ID, Element FROM tblentries;
 
 The problem is that this query, even if very fast, is logged in the slow 
 query log because it does not use index (I
 activated this option in the slow query log). Woudln't it be better if 
 such queries would be logged only in case there
 is a WHERE, ORDER or GROUP/HAVING clause ?

  Slow query log, especially with long-long-format turned on, isn't made for 
manual browsing anyway.
You'll have to use mysqldumpslow or some custom-made script to analyze it.
Queries that don't have 'where' are easy to filter then.
 
Also, is it better to do :
 SELECT ID, Element FROM tblentries;
 or
 SELECT ID, Element FROM tblentries WHERE ID  0;
 
 (In this last case, it won't be logged in the slow query log beause it 
 uses an index...)

 It won't be logged if it actually will use index. In your example it won't 
use index, full table scan will be used instead, because query optimizer is 
able to determine that all records match where condition. 
   
 -- 
 Alexey Polyakov


Re: Index update process 20+ hrs

2005-08-29 Thread Alexey Polyakov
 I'd try setting 
innodb_buffer_pool_size=8G
in my.cnf
 



-- 
Alexey Polyakov


Re: Key Buffer Size

2005-08-28 Thread Alexey Polyakov
Yeah, it's safe.

-- 
Alexey Polyakov

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



Re: query

2005-08-16 Thread Alexey Polyakov
do something like:
SELECT t1.date, (t1.field - t2.field) as diff FROM your_table t1,
your_table t2 where t1.date = t2.date + 1;

On 8/16/05, Octavian Rasnita [EMAIL PROTECTED] wrote:
 Hi,
 
 I define the previous record by date. For each record corresponds a date
 which is unique and the previous record is that that contains the yesterday
 date.
 
 Thank you.
 
 Teddy
 
 - Original Message -
 From: Felix Geerinckx [EMAIL PROTECTED]
 To: mysql@lists.mysql.com
 Sent: Tuesday, August 16, 2005 2:45 PM
 Subject: Re: query
 
 
  On 16/08/2005, Octavian Rasnita wrote:
 
   I want to create a query that selects the diference between the value
   of a field from the current record and the value of the same field
   from the previous record.
 
  How do you define current record and previous record?
  (relational databases are not spreadsheets)
 
  --
  felix
 
  --
  MySQL General Mailing List
  For list archives: http://lists.mysql.com/mysql
  To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
 
 
 
 --
 MySQL General Mailing List
 For list archives: http://lists.mysql.com/mysql
 To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
 
 


-- 
Alexey Polyakov

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



Re: best practices for finding duplicate chunks

2005-08-14 Thread Alexey Polyakov
You can modify the algorithm I proposed to find groups of records that
are likely to have duplicate chunks. Simply record only a part of
hashes, something like: if md5(concat(word1,word2,...,word20))%32=0.
Disk usage for this table will be maybe 60 bytes per record, if your
average word is 8 bytes (counting whitespace), then disk space you'll
need is about 25% of data size.
After groups of record are found, you can do brute-force indexing to
find duplicate chunks.

On 8/15/05, Gerald Taylor [EMAIL PROTECTED] wrote:
 Thanks for your answer.  It would certainly work provided having
 enough disk space to do that.  I thought something like
 that but was hoping I can leverage fulltext  and just
 record the fulltext result between a each record
 and each other record. Then I can group all records that
 highly correlate and maybe do a much smaller scale version of
 the brute force indexing thing that you are proposing, i.e. only
 do it on a group of records that we already know  have a high
 correlation, ie a high probability of sharing a chunk in common
   Then when done I can throw away that data
 and do another group.  What do you think?   Processing cycles I have
 but easy disk space I don't.

-- 
Alexey Polyakov

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



Re: A little help with mysql's Query Cache configuration

2005-08-14 Thread Alexey Polyakov
query_cache_size - a total size of memory that server utilizes for
query caching.
query_cache_limit - maximum size of result set that can be cached.
I'd suggest leaving query_cache_limit at 1 mb (the default value), and
tune query_cache_size until you have reasonably low
qcache_lowmem_prunes value.



On 8/15/05, Maxim Vexler [EMAIL PROTECTED] wrote:
 Mysql's query cache has two option's [query_cache_limit] and 
 [query_cache_size].
 The documentation is not clear (for me) on their purpose and correct
 usage tactics.
 
 What does the [query_cache_size] sets, the maximum memory space a
 single query can utilize ? Is it wise to set it to the same size as
 [query_cache_limit] ?
 
 How much memory would you recommend setting the caching to, if I have
 1GB on the system, and it runs httpd/php  mysql all together ?
 
 
 I've also included a dump from our live server, for which I have
 configured the query cache. for reference (or criticism) :
 
 mysql SHOW STATUS LIKE 'Qcache%';
 +-+-+
 | Variable_name   | Value   |
 +-+-+
 | Qcache_queries_in_cache | 1007|
 | Qcache_inserts  | 98199   |
 | Qcache_hits | 97128   |
 | Qcache_lowmem_prunes| 49330   |
 | Qcache_not_cached   | 671 |
 | Qcache_free_memory  | 1063112 |
 | Qcache_free_blocks  | 340 |
 | Qcache_total_blocks | 2374|
 +-+-+
 8 rows in set (0.00 sec)
 
 mysql SHOW global VARIABLES like 'query_cache%';
 +---+-+
 | Variable_name | Value   |
 +---+-+
 | query_cache_limit | 5242880 |
 | query_cache_size  | 3145728 |
 | query_cache_type  | ON  |
 +---+-+
 3 rows in set (0.00 sec)
 
 
 Thank you.
 
 --
 Cheers,
 Maxim Vexler (hq4ever).
 
 Do u GNU ?
 
 --
 MySQL General Mailing List
 For list archives: http://lists.mysql.com/mysql
 To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
 
 


-- 
Alexey Polyakov

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



Re: Replication, charset / collations Problem

2005-08-09 Thread Alexey Polyakov
 The only idea, which came into my mind, is that the server use different
 default charsets or collations. I checked the configurations and can't
 find a difference. Is there a possibility to check the default charsets
 and collations on the running server ?

If charsets/collations are not set explicitly in my.cnf, server could
be using ones specified during compilation.
To check charsets and collations on the running server do:
show global variables like 'c%';

-- 
Alexey Polyakov

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