Dear all,
I know that there is a MERGE engine in mysql.
It's great.
I want to know is there a way to make new log tables and new merge table
based on some criteria.
Let me explain more with an example.
I have a log_2004_09_01 table and a MERGE table on it called log.
I want to automatically make
Hi,
select * from t1,t2
left join t3 on t3.itemid=t1.itemid
mysql4.1 works, but mysql5.0 shows Unknown column 't1.itemid' in 'on clause'
If change into
select * from t2,t1
left join t3 on t3.itemid=t1.itemid
mysql5.0 works
Shuming　Wang
Dear MySQL developers and users,
With the just released MySQL 5.1.12 Beta version we now have an
excellent platform for testing the pluggable storage engine API.
PrimeBase XT is the first engine to take full advantage of this new
feature in MySQL.
The PBXT 0.9.73 release demonstrates the
Ah well, wishful thinking I guess. I guess I thought that at least the
recommendations would be deterministic. Fwiw, there would still be human
judgment in the end to decide which covering/index recommendations to
actually create.
-Original Message-
From: Dan Buettner [mailto:[EMAIL PROTE
H. I actually think this would be somewhat difficult to write,
Robert. Parsing the queries would be complex enough given the
different ways one can construct SQL. Also it would have to examine
the cardinality of the data in each column to determine if indexing
would be worthwhile vs. a tabl
Hi,
I was looking at the CREATE TABLE syntax and I saw this reference definition
for InnoDB tables:
reference_definition:
REFERENCES tbl_name [(index_col_name,...)]
[MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
[ON DELETE reference_option]
[ON UPDATE reference_option]
reference_option:
RESTRICT
Hi,
I was looking at the CREATE TABLE syntax and I saw this reference definition
for InnoDB tables:
reference_definition:
REFERENCES tbl_name [(index_col_name,...)]
[MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
[ON DELETE reference_option]
[ON UPDATE reference_option]
reference_option:
RESTRICT
I'm looking for a tool that could parse a boat load of various queries
using complex joins and subqueries, analyze each, and print out the
optimal covering indices that could be used on each table for each
query. It would have to take into consideration stuff like a WHERE
expression that could not
John,
Things to consider are that only one index can be used in a query, and it's
what's in your "where" clause that's important. Therefore, your search
("where bid = ...") will only use an index that has "bid" as the first
column in it. Therefore your multicolumn index wouldn't be used, as "id"
Ok.. Disregard... the spaces I added for troubleshooting after the
commas fubar'd it.
I think you want to create separate indexes. Indexes are basically a sorted list. So a single index on all those fields would sort
the data first by id, then bid, then title,...
If id is unique, then there is absolutely no reason to add other fields to the index. Think of a compound index as a f
I have a script that builds a data file. The data looks like this:
"62527427012682984", "191151", "177628526", "3634025281", "1", "58400",
"80", "1899", "", "2006/10/02 23:15:02", "19",
"47","","2006-11-02-231557-cust.txt", "0", "0", "IKE", "ESP: AES-256 +
SHA1", "cx-ccb_vpn", "Cx-CCB", "", ""
"62
> > InterBase had two-phase commits ages ago, Firebird inherited it.
> >
> > If there's anything specific you want to know, ask
>
> I *am* asking — where is the specific piece of documentation?
On two-phase commits? I guess it's the IB 6 docs where you have
to read that, or get a copy of Helen Bo
13 matches
Mail list logo
