Hey list,
I noticed a table that was trying to fill the disk before the weekend, so I
quickly set up an event to gradually clean it out. Yesterday, however, I
returned to find 400+ jobs in state updating. I disabled the event, but the
jobs hadn't cleared up today, so I had to kill them.
I
i used mysql_tzinfo_to_sql utility to create timezone_* database after
upgrading zoneinfo in my host.
after that i am seeing this mismatch.
'America/Sao_Paulo' (http://www.timeanddate.com/worldclock/city.html?n=233) and
'America/Buenos_Aires'
Hi all,
I'm busy setting up replication and have encountered what looks like a bug
in mysqldump. The following commands work perfectly:
Running the following commands in the mysql client on the slave:
stop slave;
reset slave;
create database dbName;
CHANGE MASTER TO MASTER_HOST='masterHost',
To: mysql@lists.mysql.com
Subject: Possible bug in mysqldump?
Hi all,
I'm busy setting up replication and have encountered what looks like a bug
in mysqldump. The following commands work perfectly:
Running the following commands in the mysql client on the slave:
stop slave;
reset slave;
create database
Message-
From: Mark Maunder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2008 3:02 AM
To: mysql@lists.mysql.com
Subject: Possible bug in mysqldump?
Hi all,
I'm busy setting up replication and have encountered what looks like a bug
in mysqldump. The following commands work
.
From: Mark Maunder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2008 12:17 PM
To: Rolando Edwards
Cc: mysql@lists.mysql.com
Subject: Re: Possible bug in mysqldump?
Thanks for the reply Rolando.
In both the examples I provided (pipe and text file) the CHANGE MASTER
*To:* Rolando Edwards
*Cc:* mysql@lists.mysql.com
*Subject:* Re: Possible bug in mysqldump?
Thanks for the reply Rolando.
In both the examples I provided (pipe and text file) the CHANGE MASTER
command appears at the top of the data import and is uncommented and
therefore executes before the data
Mathieu Bruneau wrote:
I never tried the falcon engine, but could it be that mysql is running
out of file descriptor ?
That's less likely with Falcon than with engines that put each
table and index in its own file. By default, Falcon tables share
a single tablespace.
Regards,
Ann
--
Mariella Petrini wrote:
...MySQL 6.0.2 with Falcon on Linux with Debian 4.
I have compiled the source code for 64 bit executable.
The system is an Intel 2 cpus 4 cores each, with 8 GB
of RAM.
After having created
approximately 8,500 empty tables mysqld server was
still alive, you could
I have re-run and job and I was able to repeat the
problem.
Find attached the mysql server error log with all the
tarces.
Could you please help ?
Thanks,
Mariella
--- Mariella Petrini [EMAIL PROTECTED]
wrote:
Hi All,
I have started using MySQL 6.0.2 with Falcon on
Linux
with Debian
I never tried the falcon engine, but could it be that mysql is running
out of file descriptor ?
I think debian is limited to something around 8k per user by default.
Check your pam settings and your ulimit ... Database usually use a lot
of file handle and it's generally safe to increase it.
If Debian is limited to create files over 8k, it can be the reason of the
problem.
Falcon seems not create data file for tables, but still create .frm files
for each tables.
--
Jaemyung Kim
2007/9/9, Mathieu Bruneau [EMAIL PROTECTED]:
I never tried the falcon engine, but could it be that
I don't think that is the problem.
I have been able to create over a 1,000,000 of tables with MySQL 5.1.21 and
different storage engines with the same environment (I had already ulimit set).
Thanks,
Mariella
Mathieu Bruneau [EMAIL PROTECTED] wrote: I never tried the falcon engine, but
could
Hi All,
I have started using MySQL 6.0.2 with Falcon on Linux
with Debian 4.
I have compiled the source code for 64 bit executable.
The system is an Intel 2 cpus 4 cores each, with 8 GB
of RAM.
I have started creating tables (without partitioning)
whit engine type Falcon. After having created
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
We have general logging enabled on our mysql server via a my.cnf
setting. The log records an entry when the server restarts, but does not
record any queries. Is this a bug? or have I missed something.
In my.cnf
[mysqld]
log=query.log
Contents
Peter Brawley [EMAIL PROTECTED] wrote on 10/12/2005 04:27:18
PM:
James,
Both ...
SELECT ...
FROM a, b LEFT JOIN c ON a.x=c.y
and
SELECT ...
FROM a
LEFT JOIN B USING (x )
LEFT JOIN c ON a.x=c.y
work up to and including version 5.0.10, not in 5.0.11, 12 or 13.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to the complexity of my query I don't know how to get this down to a
simple test case to demonstrate the error.
This works under mysql 4.1.8 btw, so it is failing due to a change
introduced recently. It also worked under mysql 5.0.9, but I
James Black [EMAIL PROTECTED] wrote on 10/12/2005 09:57:51 AM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to the complexity of my query I don't know how to get this down to a
simple test case to demonstrate the error.
This works under mysql 4.1.8 btw, so it is failing due to a
James,
You can reproduce that error by writing ...
SELECT ...
FROM a, b INNER JOIN c ON a.x=c.y
The error goes away if you instead write ...
SELECT ...
FROM b, a INNER JOIN c ON A.x=c.y
so you might try swapping
FROM items i
, nams.netids n
PB
-
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Brawley wrote:
James,
You can reproduce that error by writing ...
SELECT ...
FROM a, b INNER JOIN c ON a.x=c.y
The error goes away if you instead write ...
SELECT ...
FROM b, a INNER JOIN c ON A.x=c.y
I will try it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Brawley wrote:
James,
You can reproduce that error by writing ...
SELECT ...
FROM a, b INNER JOIN c ON a.x=c.y
The error goes away if you instead write ...
SELECT ...
FROM b, a INNER JOIN c ON A.x=c.y
so you might try
James Black [EMAIL PROTECTED] wrote on 10/12/2005 02:06:26 PM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Brawley wrote:
James,
You can reproduce that error by writing ...
SELECT ...
FROM a, b INNER JOIN c ON a.x=c.y
The error goes away if you instead write
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
SELECT...
FROM items i
INNER JOIN nams.netids n
INNER JOIN ...
...
Does the problem remain? If it goes away, this would be useful information
to include in your bug report.
Thank you for the suggestion, but it led
James,
Both ...
SELECT ...
FROM a, b LEFT JOIN c ON a.x=c.y
and
SELECT ...
FROM a
LEFT JOIN B USING (x )
LEFT JOIN c ON a.x=c.y
work up to and including version 5.0.10, not in 5.0.11, 12 or 13.
http://bugs.mysql.com/bug.php?id=13832 reports...
"The two statements below are quite
Scott Klarenbach [EMAIL PROTECTED] writes:
I'm using Mysql 5.0.7 and I've noticed the following very strange
functionality, perhaps someone can shed some light on it for me.
Try using the EXPLAIN statement to get some insight into what MySQL
is thinking.
Scott.
--
MySQL General Mailing
I'm using Mysql 5.0.7 and I've noticed the following very strange
functionality, perhaps someone can shed some light on it for me.
2 Tables (Request and Inventory)
Request
id (int),
partNumber varchar(60)
Inventory
id(int),
MPN varchar(60),
MPNClean varchar(60)
I have about 1500
Description:
There appears to be a type promotion problem involving sql statements which
include a 'between' comparison and a decimal type field is one of the operands.
How-To-Repeat:
CREATE TABLE `foo1` (
`test1` decimal(7,2) NOT NULL default '0.00',
`test2` decimal(7,2) NOT NULL
I have confirmed that this problem exhibits itself on the Mysql AB
compiled binaries that are compiled with gcc, both Standard and Max, but
does _not_ exhibit itself on the Mysql AB binary built with the Intel C++
Compiler 8.1 (mysql-standard-4.1.12-pc-linux-gnu-i686-icc-glibc23.tar.gz).
I have
The problem is something fairly simple but yet MySQL seems to make this
complicated. Essentially, find a list of customers who have not bought product
X ever. (Customers have orders, orders have order line items). All 3 coworkers
independently arrived at the same sql which failed to work.
From: James Nobis
SELECT DISTINCT Customer.id, Customer.name
FROM Customer
LEFT JOIN `Order` ON Customer.id = Order.customer_id
INNER JOIN OrderLines ON Order.id = OrderLines.order_id
AND OrderLines.product_id =9
WHERE Order.customer_id IS NULL
I expect customers to have placed at least one
James Nobis [EMAIL PROTECTED] wrote on 04/21/2005
10:44:07 AM:
The problem is something fairly simple but yet MySQL seems to make this
complicated. Essentially, find a list of customers who have not
bought product
X ever. (Customers have orders, orders have order line items). All
3
There is nothing wrong with what MySQL is doing. Your query is
incorrect for what you are looking for. Step through your query and
you'll see your error.
SELECT DISTINCT Customer.id, Customer.name
FROM Customer
LEFT JOIN `Order` ON Customer.id = Order.customer_id
You now have a list of the all
Thanks everyone for such quick and thorough responses!
Quoting [EMAIL PROTECTED]:
James Nobis [EMAIL PROTECTED] wrote on 04/21/2005
10:44:07 AM:
The problem is something fairly simple but yet MySQL seems to make this
complicated. Essentially, find a list of customers who have not
bought product
X
I have table with only one column set to latin1_general_ci collation,
and I get following error:
*Illegal mix of collations (latin1_general_cs,IMPLICIT) and
(utf8_general_ci,COERCIBLE) for operation '='*
Client (PHP5 with mysql functions) uses utf-8 character set. MySQL is
4.1.10a. When I change
Hello.
The value of wait_timeout is initialized from wait_timeout variable or
from the global interactive_timeout variable, depending on the type of client.
Put interactive_timeout=10 in your config file. See:
http://dev.mysql.com/doc/mysql/en/Server_system_variables.html
Andrew
Hi all,
In version 4.0.18 when setting the wait_timeout variable to 10 in
my.cnf, it seems to work when looking at 'mysqladmin variables' as it is
indeed showing up as 10.
However, when in the mysql client and I do a 'show variables' it is
showing up with the default value of 28800.
I'm certain
Hello,
I have a query that works fine on 4.0.20 but doesn't work in 4.1.7.
I want to search all the rows of table AULE that don't have a record
in table OCCUPAZIONI so the query is:
select AUL_ID, OCC_ID from
AULE
left join OCCUPAZIONI on OCC_ID_AUL=AUL_ID and OCC_DATA='2004-11-10'
where
[EMAIL PROTECTED]
To: Leonardo Javier Belén [EMAIL PROTECTED]
Sent: Wednesday, July 28, 2004 9:34 AM
Subject: SV: A possible bug
Hi Leonardo
i had a similar problem, it was with InnoDB tables, so i changed these
values:
# Set buffer pool size to 50-80% of your computer's memory
set-variable
Hi all,
I am using MySQL ver. 4.1.3-beta on Windows 2000 pro and I found that,
whenever i try to export data using the into outfile clause of the select
command the server hangs and i need to restart the service. Has anyone faced
the same problem, and if it is, how have you resolve it?
I
I have been running into problems with mysqldump. I have not been able to figure out
why mysqldump isnt working as I hope it would. Anyway I thought I'll make the
mysql-list aware of the problem and hopefully it will help someone. Or better yet
someone knows what I am doing wrong and could
I have a table with a column defined as the following.
hash CHAR(16) BINARY NOT NULL
Most data inserts fine. However, if data has trailing white space
(ASCII character 32), it seems to be getting truncated by MySQL during
the insert, such that subsequent queries to find the values fail. Full
On Thu 2003-03-20 at 14:01:52 -0500, [EMAIL PROTECTED] wrote:
I have a table with a column defined as the following.
hash CHAR(16) BINARY NOT NULL
Most data inserts fine. However, if data has trailing white space
(ASCII character 32), it seems to be getting truncated by MySQL during
the
To replicate:
1. Start with a machine running Pentium 4, Windows XP Pro.
2. Map a New Network Place to:
\\somecomputer\C$
Where \\somecomputer contains an install, in the root directory, (i.e.
C:\mysql,) of mysql already. The remote install in this case was version
3.23.56.
3.
:
workaround: use a symlink from $PREFIX/var to the directory you wish
to use
Submitter-Id: [EMAIL PROTECTED]
Originator:MySQL Server
Organization:
MySQL support: none
Synopsis: possible bug with --localstatedir=/abcd
Severity: non-critical
Priority: low
Category
Rich,
Friday, July 26, 2002, 5:59:37 PM, you wrote:
RA Looks as if the MySQL DB crashed and recovered.
RA Linux 2.4.18-5smp #1 SMP
RA MySQL version 3.23.51
From the MySQL server while running mtop 26JUL02 ~6:45AM PST:
RA Unable to execute show procs [Lost connection to MySQL server during
Looks as if the MySQL DB crashed and recovered.
Linux 2.4.18-5smp #1 SMP
MySQL version 3.23.51
From the MySQL server while running mtop 26JUL02 ~6:45AM PST:
Unable to execute show procs [Lost connection to MySQL server during query]
Stack Trace:
at main::__ANON__(/usr/local/bin/mtop:446)
Pada Fri, 26 Jul 2002 07:59:37 -0700
Rich Amick [EMAIL PROTECTED] menulis :
Searched G for mysqld_list_processes:
The above happens if a new user logs in at the same time you do
mysql_list_processes(). This is fixed in the newest MySQL 3.22
version!
--We are using version 3.23.51 -
Chuck,
- Original Message -
From: Chuck Simmons [EMAIL PROTECTED]
Newsgroups: mailing.database.mysql
Sent: Tuesday, July 09, 2002 4:29 AM
Subject: possible bug: alter table trashed foreign key constraints in innodb
sql query
In version 3.23.49a when using an innodb table, alter
Chuck,
Tuesday, July 09, 2002, 4:26:31 AM, you wrote:
CS In version 3.23.49a when using an innodb table, alter table appears to
CS corrupt foreign key constraints. Try the following test case:
It's described in the MySQL manual:
http://www.mysql.com/doc/S/E/SEC446.html
and fixed since
sql query
In version 3.23.49a when using an innodb table, alter table appears to
corrupt foreign key constraints. Try the following test case:
create table test_base (
base_id int not null,
primary key (base_id)
) type = innodb;
create table test_ref (
base_id int
I have encountered a strange problem with the enum type in version
3.23.49. It may be a bug, but I'd be grateful to hear comments.
Here's a short example which illustrates the problem. First, I create
a table with an enum column whose allowed elements are single letters,
including a single
Hi,
first of all: I'm currently not reading this mailing list,
so if you answer I would be happy to receive a Cc:
I'm currently trying to switch a web site on a complete
new machine. The old machine was runnig MySQL 3.22.32,
the new machine runs on 3.23.49
The application used Phorum for
Hello,
I have a problem in an Apache module which connects to MySQL using C
API for counting banner views and clicks.
This module creates a report table for each day. This table is called
report_MMDD, where MMDD is the current day. To keep thing
simple I just make following query
Robert,
Wednesday, May 22, 2002, 12:18:22 PM, you wrote:
RV I have a problem in an Apache module which connects to MySQL using C
RV API for counting banner views and clicks.
RV This module creates a report table for each day. This table is called
RV report_MMDD, where MMDD is the
Hi Egor,
Thanks for your reply.
What table was deleted? report_YYYMMDD?
Yes.
RV MySQL Log file says nothing.
Nothing about table delete or nothing about error?
Nope.
Robert Vetter
Internet Application Developer
Kontor23 GmbH
Ottenser Hauptstrasse 56-62
22765 Hamburg
Tel.: 040/380893-14
, 2002 3:16 AM
Heikki Subject: Re: InnoDB, possible bug?
I am using mysql 4.0.1-alpha on Linux 2.4.18, the info you requested is:
select count(*) from newsentries10 where playerid=28575 and type=2;
+--+
| count(*) |
+--+
| 4218 |
+--+
1 row in set (13.81 sec)
mysql
Hi!
Michael == Michael B Venezia [EMAIL PROTECTED] writes:
Description:
MichaelPossible Bug in UPDATE in MySQL 4.0.1
cut
Michael Attempting backtrace. You can use the following information to find out
Michael where mysqld died. If you see no messages after this, something went
: InnoDB, possible bug?
Hello,
I've just switched to InnoDB table from myISAM and it's been running
pretty
smoothly except on this SQL statement it doesn't use any indexes when
there
are, and therefore is very slow.
mysql explain select
pn.timestamp,ne.viewpoint,pn.id,pn.type,ne.type
On Tue, 21 May 2002, Michael Widenius wrote:
Hi!
Michael == Michael B Venezia [EMAIL PROTECTED] writes:
Description:
Michael Possible Bug in UPDATE in MySQL 4.0.1
cut
Michael Attempting backtrace. You can use the following information to find out
Michael where mysqld died
(0.00 sec)
Andrei Cojocaru
[EMAIL PROTECTED]
- Original Message -
From: Heikki Tuuri [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 12:40 PM
Subject: Re: InnoDB, possible bug?
Andrei,
how many rows in ne satisfy
(1) ne.playerid=28575,
(2) ne.type=2?
What
and latest news on InnoDB
- Original Message -
From: Andrei Cojocaru [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]; Mysql List
[EMAIL PROTECTED]
Sent: Wednesday, May 22, 2002 3:16 AM
Subject: Re: InnoDB, possible bug?
I am using mysql 4.0.1-alpha on Linux 2.4.18, the info you requested
Hello,
I've just switched to InnoDB table from myISAM and it's been running pretty
smoothly except on this SQL statement it doesn't use any indexes when there
are, and therefore is very slow.
mysql explain select
pn.timestamp,ne.viewpoint,pn.id,pn.type,ne.type,ne.newsid,ne.hidestamp from
Michael,
Sunday, May 19, 2002, 12:56:00 PM, you wrote:
MBV Description:
MBV Possible Bug in UPDATE in MySQL 4.0.1
MBV The following is the message in the error log...
MBV Number of processes running now: 0
MBV 020519 04:55:30 mysqld restarted
MBV 020519 4:55:30 InnoDB
Description:
Possible Bug in UPDATE in MySQL 4.0.1
The following is the message in the error log...
Number of processes running now: 0
020519 04:55:30 mysqld restarted
020519 4:55:30 InnoDB: Started
/usr/local/mysql/bin/mysqld: ready for connections
mysqld got signal 11
I forgot to point out that this is InnoDB
I've searched Google and found the following disquiteing thing:
http://www.innodb.com/oldbugs.html:
Closed or old bug reports: Almost all of these bugs have been fixed. There are some
old bug reports where the cause of the bug was never found, but
I belive I have found a bug here, possibly.
The last known commands to be run on the DB that are suspicious were a join between
2 tables.
This is the info I got from the user who was workign on the DB:
He was joining between keyword and billing
select distinct(a.customerid) from
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, April 07, 2002 5:04 AM
Subject: Re: VERY URGENT, possible bug. More on: What does this error
message mean: InnoDB: Warning: difficult to find free blocks from the buffer
pool..
I belive I have found a bug here, possibly
PROTECTED]]
Sent: Wednesday, March 20, 2002 9:35 PM
To: Chetan Lavti
Subject: Re: mysqldump and foreign keys (possible Bug ??)
No, not working,
When I run the command
SHOW TABLE STATUS FROM yourdatabasename LIKE 'T';
shown in the manual (7.5.4.2 Foreign Key Constraints)
I will see the foreign key
I have realized my error. Please disregard and ignore.
- Original Message -=20
From: David Potter=20
To: [EMAIL PROTECTED]=20
Sent: Friday, March 01, 2002 1:53 PM
Subject: Possible bug or corruption ?
Hello,
I am trying to figure
I just noticed that mysqldump -d outputs
/*!4 ALTER TABLE equity_ind1 DISABLE KEYS */;
at the end of the dump of the table def...
If I understand this correctly... this will be executed
by any version of mysql version 4 and up...
That would be fine, except that since it is not dumping
Is there any kind of UPDATE query limitation that would not allow me to
make the following update?
!--
Update SQL:
UPDATE wdCaseThread SET body='Why doesn\'t this work? http://www.mysite.com'
Actual data after update:
Why doesn't this work? [http://www.mysite.com]
--
Basically my update is
Hi!
1.1) Full Text Search can, according to the manual, be performed without
the FTS index, but it is slower.
1.2) MySQL can only use 1 index per join per table.
= This means that if I specify the USE INDEX (some_non_fulltext_index),
the FTS will be performed without the index, and
Hi!
On Jan 19, Gordan Bobic wrote:
Hi!
The part that I thought could be a bug was the one you didn't quote.
I still remeber that part, there's no need to explain it again :-)
It's not a known bug as the code is rather new.
Can you create a test case for this ?
Possibly, but it could
Hi.
I thought it would be useful to share my findings. They all relate to the
4.0.1 release. It would be nice to have some clarification on whether this is
expected behaviour, whether this behaviour is wrong (i.e. bug, corrupted
index, etc), and what you guys think could be causing it.
1.1)
Hi!
On Jan 18, Gordan Bobic wrote:
Hi.
I thought it would be useful to share my findings. They all relate to the
4.0.1 release. It would be nice to have some clarification on whether this is
expected behaviour, whether this behaviour is wrong (i.e. bug, corrupted
index, etc), and what
Rich,
it was a bug. If inserts to several tables containing an auto-inc column are
wrapped inside one LOCK TABLES, InnoDB will assert in lock0lock.c, line
2843.
Workaround: remove the LOCK TABLES if you can, or LOCK just one table at a
time.
I have fixed the bug to 3.23.48. You will get a
is the correct place/procedure to report a possible bug? I think I
found one.
Karl
Karl Stubsjoen
excelbus.com/info-m
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http
I tested this with 3.23.38 and was not able to reproduce the
problem. The UPDATE works as supposed for me.
Did you compile the server yourself? If so, try an official binary. If
not, please post more information, like where you got your binary
from, which version it is and so on. Use
that the MYD file cannot be
opened.
Here it is:
#This script file for mysql shows a possible bug.
#The update statement near the bottom of the file (a) appears not to
#work (as shown by the fact that the two selects return the same result)
#(b) leaves the table clips in a state which
I have pared down my bug scenario to a single script, at the end of which I
have
failed to update my table, and have reports that the MYD file cannot be
opened.
Here it is:
#This script file for mysql shows a possible bug.
#The update statement near the bottom of the file (a) appears
I changed the script and now all is well. However I have two concerns:
1) Paranoid about the password being in this script. Is there a way around this.
2) Since I had to change the script to make it work, Is there a bug in 3.23.41??
Thanks for pointing me in the right direction.
Bill Adams
[EMAIL PROTECTED] wrote:
I changed the script and now all is well. However I have two concerns:
1) Paranoid about the password being in this script. Is there a way around this.
chown root:root /etc/rc.d/init.d/mysqld
chmod go-rx /etc/rc.d/init.d/mysqld
2) Since I had to change the script
[EMAIL PROTECTED] wrote:
I changed the script and now all is well. However I have two concerns:
1) Paranoid about the password being in this script. Is there a way around this.
chown root:root /etc/rc.d/init.d/mysqld
chmod go-rx /etc/rc.d/init.d/mysqld
Just to be clear, if the
On Sat, 20 Oct 2001 12:48:36 -0500
Eric [EMAIL PROTECTED] wrote:
I wouldn't be opposed to implementing this as a part of the join
optimizer in MySQL, in fact, I've been reading through it for a few
days now... However, it seems like it would be a large project as the
join optimizer does not
On Fri, 19 Oct 2001 13:03:02 -0500
Eric [EMAIL PROTECTED] wrote:
Well, answering my own email, what I thought was a bug is not one at
all. I was mistaken in thinking that MySQL paid any attention to the
WHERE conditions when optimizing the join order beyond determining
which keys are used
Eric writes:
Well, answering my own email, what I thought was a bug is not one at
all. I was mistaken in thinking that MySQL paid any attention to the
WHERE conditions when optimizing the join order beyond determining
which keys are used for the join, correct?
This is really terrible
I have no problem using STRAIGHT_JOIN, etc. My problem is really just
figuring out the optimal join order. Is doing a SELECT COUNT on
each of the tables I'm going to join the way to do it? Isn't there
potential for the count to take as long as the full query processing
would take (especially
The information I require is the number of rows that will come from a
SELECT which places a certain range restriction on an unindexed
attribute...and I need this to not take much time relative to actually
executing the query (constant time would be best).
eric.
On Sat, Oct 20, 2001 at
Eric writes:
I have no problem using STRAIGHT_JOIN, etc. My problem is really just
figuring out the optimal join order. Is doing a SELECT COUNT on
each of the tables I'm going to join the way to do it? Isn't there
potential for the count to take as long as the full query processing
would
Well, I would definitely have to do the count for each query; not
because my table sizes are changing (although they are at a fairly
rapid rate), but because the number of rows I want to select is vastly
different between queries. This is actually a self-join (refer to
first emails from me to
Well, answering my own email, what I thought was a bug is not one at
all. I was mistaken in thinking that MySQL paid any attention to the
WHERE conditions when optimizing the join order beyond determining
which keys are used for the join, correct?
This is really terrible for queries like mine
I am sending this again as I am desperate for some help and believe
this to be a signifigant bug if it actually is one...which it seems to
be. See below for examples.
What is quite puzzling is MySQL's estimation of the number of rows
from each of the self-joins. The conditions on alias
Getting an error message in the log saying...
fp=(nil), etc, etc, possible bug
from ibuf0ibuf.c, line 2339
What're the possible reasons I could be getting this bug?
Oh, forgot...
MySQL-max 3.23.42
innodb
Red Hat 6.2(2.2.14-6.1.1.smp)
Intel 866Mhz, 512MB Ram, 20+ GB SCSI HDD
Thanks,
Chris
Hi,
I'm getting this error with Mysql when trying to connect using a TCP
connection (not localhost connection):
ERROR 2013: Lost connection to MySQL server during query
This only happens on our Solaris Intel boxes. Our installations on
Solaris Sparc work fine. Also, if we downgrade to MySQL
On Thu, Sep 06, 2001 at 04:35:57PM -0700, Aaron Brick wrote:
good day -
i have found cases in which the daemon blocks waiting on a select() and
just plain refuses to process certain queries. since i am reading in a 60
meg file, meaning about 3.5 million queries, this consistently happens
table and 50,000 entries in other
tables.
Does anybody experienced this strange problem, too?
The last thing i found is a possible bug in merge-table implementation
of
2.23.41. After an update from 2.23.37 to 2.23.41 i got only the first
row
of the result set again and again. Maybe it's
entries in
other
tables. Does anybody experienced this strange problem, too?
Is the long query different than the other queries? Have you done an expain
on it?
The last thing i found is a possible bug in merge-table implementation
of 2.23.41. After an update from 2.23.37 to 2.23.41 i got only
]
Betreff: Re: Optimization question and possible bug
.
In the database i have a merge-table that merges 10 myisam tables.
Sometimes the loadaverage of the system raise above 50 and the
long-query-log is
filled with some query accessing the merge table. This happens 2-3
times a
day.
Only
Hi!
Sinisa == Sinisa Milivojevic [EMAIL PROTECTED] writes:
Sinisa Aaron Brick writes:
good day -
i have found cases in which the daemon blocks waiting on a select() and
just plain refuses to process certain queries. since i am reading in a 60
meg file, meaning about 3.5 million queries,
good day -
i have found cases in which the daemon blocks waiting on a select() and
just plain refuses to process certain queries. since i am reading in a 60
meg file, meaning about 3.5 million queries, this consistently happens
somewhere in the middle. i am using 3.23.41.
restarting the server
1 - 100 of 127 matches
Mail list logo
