Re: Remove 'debian-sys-maint' Account?
Hi Carlos, The debian-sys-maint account is used for two things that I am aware of: 1) the /etc/init.d/mysql stop command uses it to perform a controlled shutdown of MySQL. 2) on execution of /etc/init.d/mysql start, it uses this account to run a CHECK TABLE on all of your tables The first function is quite handy, the second is downright annoying, especially if you have any large tables, as these will take a long time to check. There is a way of stopping it from performing the table check without disabling the maintenance account, but I can't remember it off-hand. Thanks On Tue, 2010-03-02 at 13:15 -0500, Carlos Williams wrote: I am using Debian 'Squeeze' / Testing on with MySQL 5.1.41-3 installed. It is a fresh install and I was checking all the system accounts and noticed that Debian has a 'debian-sys-maint' account on 'localhost'. Has anyone ever removed this account? Do I need it or can I safely remove this account? I don't understand why it's there. I don't want to break MySQL even though there is no data or databases on this machine but I would like to keep this as clean as possible. Thanks for any input. -Carlos -- Ian Simpson System Administrator MyJobGroup -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re bug#45458
Hi, I just filed http://bugs.mysql.com/bug.php?id=51687 which is very related to your bug#45458. If you would care to look at it and provide feedback, I would appreciate it. /Jonas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Remove 'debian-sys-maint' Account?
Hi ALL, You will find all the details you need to set up debian-sys-maint account under /etc/mysql/debian.cnf GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD 'password' WITH GRANT OPTION Regards, Igor BTW, this is my First post. On Tue, Mar 2, 2010 at 6:15 PM, Carlos Williams carlosw...@gmail.comwrote: I am using Debian 'Squeeze' / Testing on with MySQL 5.1.41-3 installed. It is a fresh install and I was checking all the system accounts and noticed that Debian has a 'debian-sys-maint' account on 'localhost'. Has anyone ever removed this account? Do I need it or can I safely remove this account? I don't understand why it's there. I don't want to break MySQL even though there is no data or databases on this machine but I would like to keep this as clean as possible. Thanks for any input. -Carlos -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=nixofort...@googlemail.com
Re: Remove 'debian-sys-maint' Account?
On Tue, Mar 2, 2010 at 7:15 PM, Carlos Williams carlosw...@gmail.comwrote: I am using Debian 'Squeeze' / Testing on with MySQL 5.1.41-3 installed. It is a fresh install and I was checking all the system accounts and noticed that Debian has a 'debian-sys-maint' account on 'localhost'. Has anyone ever removed this account? Do I need it or can I safely remove this account? I don't understand why it's there. I don't want to break MySQL even though there is no data or databases on this machine but I would like to keep this as clean as possible. As Ian already indicated, this is an administrative account used by Debian for the system operations they do. It'll probably also be used when you upgrade packages and similar things. I would recommend that you keep it, as it's only there for localhost anyway, and the credentials are in /etc/mysql/debian.cnf with restricted readability. I also tend to use those credentials for any maintenance scripts I run myself, so in that way it actually prevents clutter for me :-) -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
Re: Re bug#45458
Hello Jonas,
Thank you for filing this feature request. Are there plans to add
support for clustered indexes in MySQL soon? This is something I have
been researching on and off for a while now. Here are my thoughts.
It seems that there are two parts to this feature request:
1) a new flag that allows the storage engine to report that an index
is clustered
2) changes to the optimizer to properly support clustered keys.
I like #1. The way that I dealt with it was not as good. I added
handler::supports_clustered_keys(), and used that function and
HA_CLUSTERING from my patch to determine if an index is clustered.
Your method is better.
As for #2, I do not think it is enough. Here are two other locations
of code I know that will need to be modified:
1) find_shortest_key in sql/sql_select.cc. (This will be an addition
to MySQL bug #39653)
2) get_best_ror_intersect in sql/opt_range.cc. This is for
index_merge. A patch of what I have done is in the attached file
9-index_merge_clustering.txt. This patch was the result of a long
thread on the internals alias (which you may want to CC for this
discussion). The link to the thread is
http://lists.mysql.com/internals/36977.
There may be more places that need to be modified. I think the
approach to finding out if other places need to be modified is to
pattern match off of how the optimizer deals with clustered v.
non-clustered primary keys. It does so by having a function
handler::primary_key_is_clustered. I think one needs to search the
optimizer for all instances of this function, see why it is being
called, and see if it applies to clustered v. non-clustered secondary
keys as well.
-Zardosht
On Wed, Mar 3, 2010 at 5:57 AM, Jonas Oreland jo...@mysql.com wrote:
Hi,
I just filed http://bugs.mysql.com/bug.php?id=51687
which is very related to your bug#45458.
If you would care to look at it and provide feedback,
I would appreciate it.
/Jonas
Index: sql/opt_range.cc
===
--- sql/opt_range.cc(revision 17423)
+++ sql/opt_range.cc(revision 17424)
@@ -4525,6 +4525,7 @@ TRP_ROR_INTERSECT *get_best_ror_intersect(const PA
ROR_SCAN_INFO *cpk_scan= NULL;
uint cpk_no;
bool cpk_scan_used= FALSE;
+ bool supports_clustered_keys = param-table-file-supports_clustered_keys();
if (!(tree-ror_scans= (ROR_SCAN_INFO**)alloc_root(param-mem_root,
sizeof(ROR_SCAN_INFO*)*
@@ -4536,8 +4537,20 @@ TRP_ROR_INTERSECT *get_best_ror_intersect(const PA
for (idx= 0, cur_ror_scan= tree-ror_scans; idx param-keys; idx++)
{
ROR_SCAN_INFO *scan;
+uint keyno= param-real_keynr[idx];
+
if (!tree-ror_scans_map.is_set(idx))
+{
continue;
+}
+/*
+ Ignore clustering keys.
+*/
+if (keyno != cpk_no param-table-key_info[keyno].flags HA_CLUSTERING
supports_clustered_keys)
+{
+ tree-n_ror_scans--;
+ continue;
+}
if (!(scan= make_ror_scan(param, idx, tree-keys[idx])))
return NULL;
if (param-real_keynr[idx] == cpk_no)
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Re bug#45458
Unless I'm very much mistaken, InnoDB tables always have a clustered index as their primary key. On Wed, Mar 3, 2010 at 2:58 PM, Zardosht Kasheff zardo...@gmail.com wrote: Hello Jonas, Thank you for filing this feature request. Are there plans to add support for clustered indexes in MySQL soon? This is something I have been researching on and off for a while now. Here are my thoughts. It seems that there are two parts to this feature request: 1) a new flag that allows the storage engine to report that an index is clustered 2) changes to the optimizer to properly support clustered keys. I like #1. The way that I dealt with it was not as good. I added handler::supports_clustered_keys(), and used that function and HA_CLUSTERING from my patch to determine if an index is clustered. Your method is better. As for #2, I do not think it is enough. Here are two other locations of code I know that will need to be modified: 1) find_shortest_key in sql/sql_select.cc. (This will be an addition to MySQL bug #39653) 2) get_best_ror_intersect in sql/opt_range.cc. This is for index_merge. A patch of what I have done is in the attached file 9-index_merge_clustering.txt. This patch was the result of a long thread on the internals alias (which you may want to CC for this discussion). The link to the thread is http://lists.mysql.com/internals/36977. There may be more places that need to be modified. I think the approach to finding out if other places need to be modified is to pattern match off of how the optimizer deals with clustered v. non-clustered primary keys. It does so by having a function handler::primary_key_is_clustered. I think one needs to search the optimizer for all instances of this function, see why it is being called, and see if it applies to clustered v. non-clustered secondary keys as well. -Zardosht On Wed, Mar 3, 2010 at 5:57 AM, Jonas Oreland jo...@mysql.com wrote: Hi, I just filed http://bugs.mysql.com/bug.php?id=51687 which is very related to your bug#45458. If you would care to look at it and provide feedback, I would appreciate it. /Jonas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
RE: Re bug#45458
Yes, but the optimizer doesn't know that. -Original Message- From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De Meersman Sent: Wednesday, March 03, 2010 6:16 AM To: Zardosht Kasheff Cc: Jonas Oreland; mysql@lists.mysql.com Subject: Re: Re bug#45458 Unless I'm very much mistaken, InnoDB tables always have a clustered index as their primary key. On Wed, Mar 3, 2010 at 2:58 PM, Zardosht Kasheff zardo...@gmail.com wrote: Hello Jonas, Thank you for filing this feature request. Are there plans to add support for clustered indexes in MySQL soon? This is something I have been researching on and off for a while now. Here are my thoughts. It seems that there are two parts to this feature request: 1) a new flag that allows the storage engine to report that an index is clustered 2) changes to the optimizer to properly support clustered keys. I like #1. The way that I dealt with it was not as good. I added handler::supports_clustered_keys(), and used that function and HA_CLUSTERING from my patch to determine if an index is clustered. Your method is better. As for #2, I do not think it is enough. Here are two other locations of code I know that will need to be modified: 1) find_shortest_key in sql/sql_select.cc. (This will be an addition to MySQL bug #39653) 2) get_best_ror_intersect in sql/opt_range.cc. This is for index_merge. A patch of what I have done is in the attached file 9-index_merge_clustering.txt. This patch was the result of a long thread on the internals alias (which you may want to CC for this discussion). The link to the thread is http://lists.mysql.com/internals/36977. There may be more places that need to be modified. I think the approach to finding out if other places need to be modified is to pattern match off of how the optimizer deals with clustered v. non-clustered primary keys. It does so by having a function handler::primary_key_is_clustered. I think one needs to search the optimizer for all instances of this function, see why it is being called, and see if it applies to clustered v. non-clustered secondary keys as well. -Zardosht On Wed, Mar 3, 2010 at 5:57 AM, Jonas Oreland jo...@mysql.com wrote: Hi, I just filed http://bugs.mysql.com/bug.php?id=51687 which is very related to your bug#45458. If you would care to look at it and provide feedback, I would appreciate it. /Jonas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Re bug#45458
I believe the optimizer does know that InnoDB has a clustered primary key, because ha_innobase::primary_key_is_clustered returns true On Wed, Mar 3, 2010 at 2:22 PM, Gavin Towey gto...@ffn.com wrote: Yes, but the optimizer doesn't know that. -Original Message- From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De Meersman Sent: Wednesday, March 03, 2010 6:16 AM To: Zardosht Kasheff Cc: Jonas Oreland; mysql@lists.mysql.com Subject: Re: Re bug#45458 Unless I'm very much mistaken, InnoDB tables always have a clustered index as their primary key. On Wed, Mar 3, 2010 at 2:58 PM, Zardosht Kasheff zardo...@gmail.com wrote: Hello Jonas, Thank you for filing this feature request. Are there plans to add support for clustered indexes in MySQL soon? This is something I have been researching on and off for a while now. Here are my thoughts. It seems that there are two parts to this feature request: 1) a new flag that allows the storage engine to report that an index is clustered 2) changes to the optimizer to properly support clustered keys. I like #1. The way that I dealt with it was not as good. I added handler::supports_clustered_keys(), and used that function and HA_CLUSTERING from my patch to determine if an index is clustered. Your method is better. As for #2, I do not think it is enough. Here are two other locations of code I know that will need to be modified: 1) find_shortest_key in sql/sql_select.cc. (This will be an addition to MySQL bug #39653) 2) get_best_ror_intersect in sql/opt_range.cc. This is for index_merge. A patch of what I have done is in the attached file 9-index_merge_clustering.txt. This patch was the result of a long thread on the internals alias (which you may want to CC for this discussion). The link to the thread is http://lists.mysql.com/internals/36977. There may be more places that need to be modified. I think the approach to finding out if other places need to be modified is to pattern match off of how the optimizer deals with clustered v. non-clustered primary keys. It does so by having a function handler::primary_key_is_clustered. I think one needs to search the optimizer for all instances of this function, see why it is being called, and see if it applies to clustered v. non-clustered secondary keys as well. -Zardosht On Wed, Mar 3, 2010 at 5:57 AM, Jonas Oreland jo...@mysql.com wrote: Hi, I just filed http://bugs.mysql.com/bug.php?id=51687 which is very related to your bug#45458. If you would care to look at it and provide feedback, I would appreciate it. /Jonas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=zardo...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Tip: Full Text Searches
Something I didn't realize about full text searches, but they can be used with multi-table views! Maybe I'm the last one on the planet to discover this, but I think this is really neat. For example, I can create a view with all the fulltext index column of the customer table (name, address, customer_profile), and link it to the sales_summary table. Now I can search on our biggest customers this month who live in Atlanta and like fly fishing so we can have a fishing derby. It is fast too. I wonder why I didn't think of this before? Am I the last one to discover this? Hmm. Anyway I thought I'd post it as a tip in case someone else wasn't aware of it. Enjoy. :-) Mike (MySQL 5.1) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: Full Text Searches
-Original Message- From: mos [mailto:mo...@fastmail.fm] Sent: Wednesday, March 03, 2010 5:14 PM To: mysql@lists.mysql.com Subject: Tip: Full Text Searches Something I didn't realize about full text searches, but they can be used with multi-table views! Maybe I'm the last one on the planet to discover this, but I think this is really neat. [JS] I never did it with a view, I just did it with a join. Works fine, lasts a long time. Regards, Jerry Schwartz The Infoshop by Global Information Incorporated 195 Farmington Ave. Farmington, CT 06032 860.674.8796 / FAX: 860.674.8341 www.the-infoshop.com For example, I can create a view with all the fulltext index column of the customer table (name, address, customer_profile), and link it to the sales_summary table. Now I can search on our biggest customers this month who live in Atlanta and like fly fishing so we can have a fishing derby. It is fast too. I wonder why I didn't think of this before? Am I the last one to discover this? Hmm. Anyway I thought I'd post it as a tip in case someone else wasn't aware of it. Enjoy. :-) Mike (MySQL 5.1) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=jschwa...@the- infoshop.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
5.1.44 community version select ordno=' ' error (2)
Hi, select * from t1 ordno qty 1 3 5 'aaa' 18 'b' 20 select * from t1 where ordno=' ' or ordno' ' ordno qty 1 3 5 'aaa' 18 'b' 20 select * from t1 where ordno=' ' ordno qty 'aaa' 18 'b' 20 mysql version 5.1.44 still with the bug Best regards! Shuming Wang
Re: 5.1.44 community version select ordno=' ' error (2)
In the last episode (Mar 04), wang shuming said: select * from t1 ordno qty 1 3 5 'aaa' 18 'b' 20 Are your first three rows really blank, or are there nonprintable characters in 'ordno' that aren't showing up here? You need to provide us with the table definition and the insert statements needed to create the t1 table and its data. Can you attach the output of mysqldump --skip-opt mydb t1 ? select * from t1 where ordno=' ' or ordno' ' ordno qty 1 3 5 'aaa' 18 'b' 20 select * from t1 where ordno=' ' ordno qty 'aaa' 18 'b' 20 mysql version 5.1.44 still with the bug Best regards! Shuming Wang -- Dan Nelson dnel...@allantgroup.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
