Skip to content

M
mariadb
Commit 7b72c14b authored by unknown's avatar unknown
Browse files
Options

Increase max package length to 512M for mysql and mysqldump. 

Faster 'read_first_row' (Fixes slow 'preparing' state)
Read constant tables earlier, which provides better optimzations when using tables with <=1 row.
This also fixes a complicated bug involving const tables.


Docs/manual.texi:
  Changelog
client/mysql.cc:
  Increase max package length to 512M
client/mysqldump.c:
  Increase max package length to 512M
dbug/dbug.c:
  Fixed wrong printf() format string.
mysql-test/t/innodb.test:
  Test for multi-table delete
sql/handler.cc:
  Faster 'read_first_row' (Fixes slow 'preparing' state)
sql/handler.h:
  Faster 'read_first_row' (Fixes slow 'preparing' state)
sql/opt_range.cc:
  More debug info.
sql/sql_select.cc:
  Read constant tables earlier, which provides better optimzations when using tables with <=1 row.
  This also fixes a complicated bug involving const tables.
sql/sql_select.h:
  Read const tables earlier
parent 879e892d
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 415 additions and 260 deletions
Docs/manual.texi
View file @ 7b72c14b
......@@ -810,14 +810,14 @@ is pushed up to 8 million terabytes (2 ^ 63 bytes).
Note, however, that operating systems have their own file size
limits. Here are some examples:
@multitable @columnfractions .5 .5
@multitable @columnfractions .6 .4
@item @strong{Operating System} @tab @strong{File Size Limit}
@item Linux-Intel 32 bit @tab 2G, 4G or more, depends on Linux version
@item Linux-Alpha @tab 8T (?)
@item Solaris 2.5.1 @tab 2G (possible 4G with patch)
@item Solaris 2.6 @tab 4G
@item Solaris 2.7 Intel @tab 4G
@item Solaris 2.7 ULTRA-SPARC @tab 8T (?)
@item Solaris 2.7 ULTRA-SPARC @tab 512G
@end multitable
On Linux 2.2 you can get bigger tables than 2G by using the LFS patch for
......@@ -5480,7 +5480,6 @@ pipes.
All of the above binaries are optimised for the Pentium Pro
processor but should work on any Intel processor >= i386.
In the following circumstances you will need to use the MySQL
configuration file:
@itemize @bullet
......@@ -5498,17 +5497,23 @@ If you want to use one of the these servers:
If you need to tune the server settings.
@end itemize
There are two configuration files with the same function:
@file{my.cnf} and @file{my.ini} file, however please note that
only of one these should can used. Both files are plain text.
The @file{my.cnf} file should be created in the root directory
of drive C and the @file{my.ini} file on the WinDir directory
e.g: @file{C:\WINDOWS} or @file{C:\WINNT}.
If your PC uses a boot loader where the C drive isn't the boot
drive, then your only option is to use the @file{my.ini} file.
Also note that if you use the @code{WinMySQLAdmin} tool, only
the @file{my.ini} file is used. The @file{\mysql\bin} directory
contains a help file with instructions for using this tool.
Normally you can use the @code{WinMySQLAdmin} tool to edit the
configuration file @code{my.ini}. In this case you don't have to worry
about the following section.
There are two configuration files with the same function: @file{my.cnf}
and @file{my.ini} file, however please note that only of one these
should be used to avoid confusion. Both files are plain text. The
@file{my.cnf} file , if used, should be created in the root directory of
drive C and the @file{my.ini} file on the WinDir directory e.g:
@file{C:\WINDOWS} or @file{C:\WINNT}. MySQL will first read the
@code{my.ini} file, followed by the @code{my.cnf} file.
If your PC uses a boot loader where the C drive isn't the boot drive,
then your only option is to use the @file{my.ini} file. Also note that
if you use the @code{WinMySQLAdmin} tool, only the @file{my.ini} file is
used by this tool. The @file{\mysql\bin} directory contains a help file
with instructions for using this tool.
Using @code{notepad.exe}, create the configuration file and
edit the base section and keys:
......@@ -5781,11 +5786,12 @@ release or the last stable release:
@itemize @bullet
@item
Normally, if you are beginning to use MySQL for the first time
or trying to port it to some system for which there is no binary
distribution, we recommend going with the stable release (currently
Version 3.23. Note that all MySQL releases are checked with the
MySQL benchmarks and an extensive test suite before each release.
Normally, if you are beginning to use MySQL for the first time or trying
to port it to some system for which there is no binary distribution, we
recommend going with the stable release (currently Version 3.23. Note
that all MySQL releases are checked with the MySQL benchmarks and an
extensive test suite before each release (even the development
releases).
@item
Otherwise, if you are running an old system and want to upgrade, but
......@@ -6046,7 +6052,8 @@ Stable tested releases are meant to appear about 1-2 times a year, but
if small bugs are found, a release with only bug fixes will be released.
@item
Working releases are meant to appear about every 1-8 weeks.
Working releases/bug fixes to old releases are meant to appear about
every 1-8 weeks.
@item
Binary distributions for some platforms will be made by us for major releases.
......@@ -6055,12 +6062,12 @@ less frequently.
@item
We usually make patches available as soon as we have located and fixed
small bugs.
small bugs. They are posted to @email{bugs@@lists.mysql.com} and will
be added to the next release.
@item
For non-critical but annoying bugs, we will make patches available if they
are sent to us. Otherwise we will combine many of them into a larger
patch.
For non-critical but annoying bugs, we will add them the MySQL source
repository and they will be fixed in the next release.
@item
If there is, by any chance, a fatal bug in a release we will make a new
......@@ -6075,6 +6082,10 @@ and things that ``must be done.'' ``Somewhat frozen'' means that we may
add small things that ``almost surely will not affect anything that's
already working.''
MySQL uses a little different naming scheme that most other products.
In general it's relatively safe to use any version that has been out for
a couple of weeks without being replaced with a new version.
@xref{Which version}.
@node MySQL binaries, Installing binary, Many versions, General Installation Issues
@subsection MySQL Binaries Compiled by MySQL AB
......@@ -19487,7 +19498,7 @@ bytes when needed. This value by default is small, to catch big (possibly
wrong) packets. You must increase this value if you are using big
@code{BLOB} columns. It should be as big as the biggest @code{BLOB} you want
to use. The protocol limits for @code{max_allowed_packet} is 16M in MySQL
3.23 and 4G in MySQL 4.0.
3.23 and 2G in MySQL 4.0.
@item @code{max_binlog_cache_size}
If a multi-statement transaction requires more than this amount of memory,
......@@ -36746,6 +36757,11 @@ The following are the known problems with @code{MERGE} tables:
@itemize @bullet
@item
@code{MERGE} table cannot maintain UNIQUE constraints over the whole
table. When you do INSERT, the data goes into the first or last table
(according to @code{INSERT_METHOD=xxx}) and this MyISAM table ensures
that the data are unique, but it knows nothing about the first MyISAM table.
@item
@code{DELETE FROM merge_table} used without a @code{WHERE}
will only clear the mapping for the table, not delete everything in the
mapped tables.
......@@ -38643,6 +38659,7 @@ Finland
* BDB characteristics:: Characteristics of @code{BDB} tables:
* BDB TODO:: Things we need to fix for BDB in the near future:
* BDB portability:: Operating systems supported by @strong{BDB}
* BDB restrictions::
* BDB errors:: Errors That May Occur When Using BDB Tables
@end menu
......@@ -38851,7 +38868,7 @@ Change to not use page locks at all when we are scanning tables.
@end itemize
@node BDB portability, BDB errors, BDB TODO, BDB
@node BDB portability, BDB restrictions, BDB TODO, BDB
@subsection Operating systems supported by @strong{BDB}
If you after having built MySQL with support for BDB tables get
......@@ -38891,8 +38908,28 @@ Linux 2.x Alpha
Max OS X
@end itemize
@node BDB restrictions, BDB errors, BDB portability, BDB
@subsection Restrictions on BDB Tables
Here follows the restrictions you have when using BDB tables:
@node BDB errors, , BDB portability, BDB
@itemize @bullet
@item
BDB tables store in the .db file the path to the file as it was created
(My guess is that this is to be able to detect locks in a multi-user
environment that supports symlinks).
The effect of this is that BDB tables are not movable between directories!
@item
When taking backups of BDB tables, you have to either use
@code{mysqldump} or take a backup of all @code{table_name.db} files and
the BDB log files. The BDB log files are the files in the base data
directory named @code{log.XXXXXX} (6 digits);
The BDB table handler stores unfinished transactions in the log files
and requires these to be present when @code{mysqld} starts.
@end itemize
@node BDB errors, , BDB restrictions, BDB
@subsection Errors That May Occur When Using BDB Tables
@itemize @bullet
......@@ -45281,6 +45318,11 @@ When a MySQL client or the @code{mysqld} server gets a packet bigger
than @code{max_allowed_packet} bytes, it issues a @code{Packet too large}
error and closes the connection.
In MySQL 3.23 the biggest possible packet is 16M (due to limits in the
client/server protocol). In MySQL 4.0.1 and up, this is only limited by
the amount on memory you have on your server (up to a theoretical
maximum of 2G).
A communication packet is a single SQL statement sent to the MySQL server
or a single row that is sent to the client.
......@@ -47090,11 +47132,6 @@ New version of netadmin. See above for details.
Atronic's MySQL client for Windows 2.0.3.0.
The home page for this can be found at @uref{http://www.artronic.hr/}.
@item @uref{http://www.mysql.com/Downloads/Win32/mysqlfront.zip}
MySQL Front, home page: @uref{http://www.mysqlfront.de/}.
Win32-Client for accessing and managing dbs, tables, table-data, indexes,
import-/export-files. (Freeware). By Ansgar Becker.
@item @uref{http://www.mysql.com/Downloads/Win32/W9xstop.zip}
Utility from Artronic to stop MySQL on win9x.
......@@ -48135,6 +48172,14 @@ Our TODO section contains what we plan to have in 4.0. @xref{TODO MySQL 4.0}.
@itemize @bullet
@item
Fixed optimization problem where a MySQL was a long time in a
"preparing" state when selecting from an empty table which had contained
a lot of rows.
@item
Fixed bug in complicated join with @code{const} tables. This fix also
improves performance a bit when referring to another table from a
@code{const} table.
@item
Fixed bug in multi table delete.
@item
Fixed bug in @code{SELECT CONCAT(argument-list) ... GROUP BY 1}.
client/mysql.cc
View file @ 7b72c14b
......@@ -477,8 +477,8 @@ static struct option long_options[] =
CHANGEABLE_VAR changeable_vars[] = {
{ "connect_timeout", (long*) &opt_connect_timeout, 0, 0, 3600*12, 0, 1},
{ "max_allowed_packet", (long*) &max_allowed_packet,16*1024L*1024L,4096,
24*1024L*1024L, MALLOC_OVERHEAD,1024},
{ "net_buffer_length",(long*) &net_buffer_length,16384,1024,24*1024*1024L,
512*1024L*1024L, MALLOC_OVERHEAD,1024},
{ "net_buffer_length",(long*) &net_buffer_length,16384,1024,512*1024*1024L,
MALLOC_OVERHEAD,1024},
{ "select_limit", (long*) &select_limit, 1000L, 1, ~0L, 0, 1},
{ "max_join_size", (long*) &max_join_size, 1000000L, 1, ~0L, 0, 1},
......
client/mysqldump.c
View file @ 7b72c14b
......@@ -147,9 +147,9 @@ static const char *load_default_groups[]= { "mysqldump","client",0 };
CHANGEABLE_VAR md_changeable_vars[] = {
{ "max_allowed_packet", (long*) &max_allowed_packet,24*1024*1024,4096,
24*1024L*1024L,MALLOC_OVERHEAD,1024},
512*1024L*1024L,MALLOC_OVERHEAD,1024},
{ "net_buffer_length", (long*) &net_buffer_length,1024*1024L-1025,4096,
24*1024L*1024L,MALLOC_OVERHEAD,1024},
512*1024L*1024L,MALLOC_OVERHEAD,1024},
{ 0, 0, 0, 0, 0, 0, 0}
};
......
dbug/dbug.c
View file @ 7b72c14b
......@@ -1928,7 +1928,7 @@ static void dbug_flush(CODE_STATE *state)
{
if (!(freopen(stack->name,"a",_db_fp_)))
{
(void) fprintf(stderr, ERR_OPEN, _db_process_);
(void) fprintf(stderr, ERR_OPEN, _db_process_, stack->name);
fflush(stderr);
_db_fp_ = stdout;
stack -> out_file = _db_fp_;
......
mysql-test/t/innodb.test
View file @ 7b72c14b
......@@ -577,3 +577,51 @@ handler t1 read t first;
--error 1109
handler t1 close;
drop table t1;
#
# Test of multi-table-delete
#
CREATE TABLE t1 (
number bigint(20) NOT NULL default '0',
cname char(15) NOT NULL default '',
carrier_id smallint(6) NOT NULL default '0',
privacy tinyint(4) NOT NULL default '0',
last_mod_date timestamp(14) NOT NULL,
last_mod_id smallint(6) NOT NULL default '0',
last_app_date timestamp(14) NOT NULL,
last_app_id smallint(6) default '-1',
version smallint(6) NOT NULL default '0',
assigned_scps int(11) default '0',
status tinyint(4) default '0'
) TYPE=InnoDB;
INSERT INTO t1 VALUES (4077711111,'SeanWheeler',90,2,20020111112846,500,00000000000000,-1,2,3,1);
INSERT INTO t1 VALUES (9197722223,'berry',90,3,20020111112809,500,20020102114532,501,4,10,0);
INSERT INTO t1 VALUES (650,'San Francisco',0,0,20011227111336,342,00000000000000,-1,1,24,1);
INSERT INTO t1 VALUES (302467,'Sue\'s Subshop',90,3,20020109113241,500,20020102115111,501,7,24,0);
INSERT INTO t1 VALUES (6014911113,'SudzCarwash',520,1,20020102115234,500,20020102115259,501,33,32768,0);
INSERT INTO t1 VALUES (333,'tubs',99,2,20020109113440,501,20020109113440,500,3,10,0);
CREATE TABLE t2 (
number bigint(20) NOT NULL default '0',
cname char(15) NOT NULL default '',
carrier_id smallint(6) NOT NULL default '0',
privacy tinyint(4) NOT NULL default '0',
last_mod_date timestamp(14) NOT NULL,
last_mod_id smallint(6) NOT NULL default '0',
last_app_date timestamp(14) NOT NULL,
last_app_id smallint(6) default '-1',
version smallint(6) NOT NULL default '0',
assigned_scps int(11) default '0',
status tinyint(4) default '0'
) TYPE=InnoDB;
INSERT INTO t2 VALUES (4077711111,'SeanWheeler',0,2,20020111112853,500,00000000000000,-1,2,3,1);
INSERT INTO t2 VALUES (9197722223,'berry',90,3,20020111112818,500,20020102114532,501,4,10,0);
INSERT INTO t2 VALUES (650,'San Francisco',90,0,20020109113158,342,00000000000000,-1,1,24,1);
INSERT INTO t2 VALUES (333,'tubs',99,2,20020109113453,501,20020109113453,500,3,10,0);
select * from t1;
select * from t2;
delete t1, t2 from t1 left join t2 on t1.number=t2.number where (t1.carrier_id=90 and t1.number=t2.number) or (t2.carrier_id=90 and t1.number=t2.number) or (t1.carrier_id=90 and t2.number is null);
select * from t1;
select * from t2;
select * from t2;
drop table t1,t2;
sql/handler.cc
View file @ 7b72c14b
......@@ -472,17 +472,36 @@ int handler::analyze(THD* thd, HA_CHECK_OPT* check_opt)
return HA_ADMIN_NOT_IMPLEMENTED;
}
/* Read first row from a table */
/*
Read first row (only) from a table
This is never called for InnoDB or BDB tables, as these table types
has the HA_NOT_EXACT_COUNT set.
*/
int handler::rnd_first(byte * buf)
int handler::read_first_row(byte * buf, uint primary_key)
{
register int error;
DBUG_ENTER("handler::rnd_first");
DBUG_ENTER("handler::read_first_row");
statistic_increment(ha_read_first_count,&LOCK_status);
(void) rnd_init();
while ((error= rnd_next(buf)) == HA_ERR_RECORD_DELETED) ;
(void) rnd_end();
/*
If there is very few deleted rows in the table, find the first row by
scanning the table.
*/
if (deleted < 10 || primary_key >= MAX_KEY)
{
(void) rnd_init();
while ((error= rnd_next(buf)) == HA_ERR_RECORD_DELETED) ;
(void) rnd_end();
}
else
{
/* Find the first row through the primary key */
(void) index_init(primary_key);
error=index_first(buf);
(void) index_end();
}
DBUG_RETURN(error);
}
......@@ -498,7 +517,7 @@ int handler::restart_rnd_next(byte *buf, byte *pos)
}
/* Set a timestamp in record */
/* Set a timestamp in record */
void handler::update_timestamp(byte *record)
{
......@@ -514,9 +533,10 @@ void handler::update_timestamp(byte *record)
return;
}
/* Updates field with field_type NEXT_NUMBER according to following:
** if field = 0 change field to the next free key in database.
*/
/*
Updates field with field_type NEXT_NUMBER according to following:
if field = 0 change field to the next free key in database.
*/
void handler::update_auto_increment()
{
......
sql/handler.h
View file @ 7b72c14b
......@@ -269,7 +269,7 @@ public:
virtual int rnd_end() { return 0; }
virtual int rnd_next(byte *buf)=0;
virtual int rnd_pos(byte * buf, byte *pos)=0;
virtual int rnd_first(byte *buf);
virtual int read_first_row(byte *buf, uint primary_key);
virtual int restart_rnd_next(byte *buf, byte *pos);
virtual ha_rows records_in_range(int inx,
const byte *start_key,uint start_key_len,
......
sql/opt_range.cc
View file @ 7b72c14b
......@@ -585,6 +585,9 @@ int SQL_SELECT::test_quick_select(key_map keys_to_use, table_map prev_tables,
uint idx;
double scan_time;
DBUG_ENTER("test_quick_select");
DBUG_PRINT("enter",("keys_to_use: %lu prev_tables: %lu const_tables: %lu",
(ulong) keys_to_use, (ulong) prev_tables,
(ulong) const_tables));
delete quick;
quick=0;
......
sql/sql_select.cc
View file @ 7b72c14b
This diff is collapsed.
sql/sql_select.h
View file @ 7b72c14b
......@@ -158,7 +158,7 @@ class JOIN {
uint send_group_parts;
bool sort_and_group,first_record,full_join,group, no_field_update;
bool do_send_rows;
table_map const_table_map,outer_join;
table_map const_table_map,found_const_table_map,outer_join;
ha_rows send_records,found_records,examined_rows,row_limit;
POSITION positions[MAX_TABLES+1],best_positions[MAX_TABLES+1];
double best_read;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7