[EMAIL PROTECTED] wrote:
Does this sound about right? Anybody see any road hazards? If not, and
this line of thinking is reasonable, should the DB with the older
records
also be replicated so that when a new old records table needs to be
created, I don't have to repeat everything on the
[EMAIL PROTECTED] wrote:
Does this sound about right? Anybody see any road hazards? If not, and
this line of thinking is reasonable, should the DB with the older records
also be replicated so that when a new old records table needs to be
created, I don't have to repeat everything on the
Kevin Burton wrote:
I want to use a merge table so that I can direct all new INSERTs to a
new merge table and migrate old data off the system by having a
continually sliding window of underlying MyISAM tables.
The problem is that of I do INSERT ... ON DUPLCATE KEY UPDATE and
that value isn't
I thought about it I was actually going to use merge tables AND
partitions to split the underlying MyISAM tables across two disks and
then partition on top.
It's POSSIBLE to use partitioning the way I want it but I'm going to
have to grok it for a bit more.
Thanks though.
Kevin
On
Paul,
One of the databases I use just switched to using merge tables and now
my queries are painfully slow. One table, initially had about 2.5
million records and now with the change this information is spread
across about 1600 tables. A simple query, say select count(*) has gone
from .04 to
I guess u had 2.5 million records splited into 1600 tables if iam not wrong :)
Why you split the tables to 1600 is there any specific count ?
Why you moved to merge table reason behind ?
Since 2.5 million records to 1600 is a huge count on nos of tables :( instead
of one ;)
--Praj
On
Hello Paul,
I suggest you reply to the mailinglist :-) ...
The developer insists that for scalability issues, this was the
answer. It is likely, for example in my deployment, that these tables
would see upwards of 10 million records or more.
Well, if there are problems with scalability, I
Martijn Tonies [EMAIL PROTECTED] wrote on 14/03/2006 11:32:10:
Hello Paul,
I suggest you reply to the mailinglist :-) ...
The developer insists that for scalability issues, this was the
answer. It is likely, for example in my deployment, that these tables
would see upwards of 10
On 3/14/06, Martijn Tonies [EMAIL PROTECTED] wrote:
Hello Paul,
I suggest you reply to the mailinglist :-) ...
The developer insists that for scalability issues, this was the
answer. It is likely, for example in my deployment, that these tables
would see upwards of 10 million records or
The developer insists that for scalability issues, this was the
answer. It is likely, for example in my deployment, that these tables
would see upwards of 10 million records or more.
Well, if there are problems with scalability, I guess you could
split it up in a few (not 1600)
Paul Halliday [EMAIL PROTECTED] wrote on 14/03/2006 12:09:10:
As an example:
There was a table called event.
This table is now broken up like this:
event _sensor_date.
So for every sensor, and every day, there is now a new table. So if I
have 20 sensors, every day I will have 20
[EMAIL PROTECTED] wrote:
Paul Halliday [EMAIL PROTECTED] wrote on 14/03/2006 12:09:10:
As an example:
There was a table called event.
This table is now broken up like this:
event _sensor_date.
So for every sensor, and every day, there is now a new table. So if I
have 20 sensors, every
nigel wood [EMAIL PROTECTED] wrote on 14/03/2006 13:09:08:
[EMAIL PROTECTED] wrote:
Paul Halliday [EMAIL PROTECTED] wrote on 14/03/2006 12:09:10:
As an example:
There was a table called event.
This table is now broken up like this:
event _sensor_date.
So for every
Hi
Simple way is show table status; there is a column Type : value MRG_MyISAM is
the base table.
--Praj
On Tue, 7 Mar 2006 14:02:44 +0100
Martijn Tonies [EMAIL PROTECTED] wrote:
Hi there,
How do you know what the sources are for a MERGE
table?
SHOW TABLE STATUS doesn't show it, as
Hi,
Simple way is show table status; there is a column Type : value MRG_MyISAM
is the base table.
No, that's not what I meant -- I meant, the merge
table uses a UNION clause to get signal where it
get it's data from.
Where can I get the sources for the merge table?
That is, what is used in the
Oh yeah got it u meant UNION clause .
Still i have no idea about that i usally see it in show create tables
statements .
Sorry :(
--Praj
On Tue, 7 Mar 2006 15:10:51 +0100
Martijn Tonies [EMAIL PROTECTED] wrote:
Hi,
Simple way is show table status; there is a column Type : value
Martijn Tonies [EMAIL PROTECTED] wrote on 03/07/2006 09:57:17 AM:
Hi,
Anyone got a clue where to get a hold of insert_method
after creating the table?
Is the SHOW CREATE TABLE output the only way to
get it?
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL,
Hello Shawn,
Thanks for replying.
INSERT_METHOD is an option valid for merge tables.
See http://dev.mysql.com/doc/refman/5.0/en/create-table.html
From what I can see, the only way to get it, is parse the
SHOW CREATE TABLE output.
Martijn Tonies
Database Workbench - tool for InterBase,
On 07/03/2006, [EMAIL PROTECTED] wrote:
insert_method ??
I thought I knew a little about databases and table design but that's
a new term for me. What does it mean and how would I apply it in
order to modify a table's contents?
From
Martijn Tonies [EMAIL PROTECTED] wrote on 03/07/2006 10:46:58 AM:
Hello Shawn,
Thanks for replying.
INSERT_METHOD is an option valid for merge tables.
See http://dev.mysql.com/doc/refman/5.0/en/create-table.html
From what I can see, the only way to get it, is parse the
SHOW CREATE
(still catching up!)
Tom,
We have similar queries where I work, and a union is the best way to
go. Leaving the tables large eats up valuable buffer space for us,
putting the logic in the client app is a bad idea (since you'd have to
do it for all apps).
In particular, our sessions table is
On Mon, May 31, 2004 at 02:03:09PM +0200, Michael Arndt wrote:
Problem for this variant: merge table has to be dropped and recreated
periodically.
during the short lag interval the log merge table
does not exist
Hi Michael,
Problem for this variant: merge table has to be dropped and recreated
periodically.
during the short lag interval the log merge table
does not exist
You don't have to drop and re-create the table. Please
On Wed, Mar 24, 2004 at 01:23:53PM +, Chris Elsworth wrote:
I'm wondering if specifying LOW_PRIORITY disables concurrent inserts
explicitly, so I'll try removing that and see if anything improves,
but in the meantime, if anyone has any advice, please share :)
Ignore that bit. Found the
Hi Tony,
shell perror 143
Error code 143: Unknown error
143 = Conflicting table definition between MERGE and mapped table
Matt
- Original Message -
From: [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 4:00 PM
Subject: Merge Tables not working...
Hello,
I've posted this
Error 143 suggests that you have conflicting table definitions.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 7:08 AM
To: [EMAIL PROTECTED]
Subject: MERGE tables error
I've created several merge tables from the command prompt. All
* [EMAIL PROTECTED]
[...]
ERROR 1016: Can't open file: 'new_master.MRG'. (errno: 143)
All table structures are identical.
Maybe not..? :)
Am I missing a basic error numbers page in the online docs? I've found a
few, but nothing comprehensive, like a page where I can enter an
error
[EMAIL PROTECTED] wrote:
The manual page for MERGE tables states the code is in gamma since 3.23.25.
But it also says you can only SELECT, DELETE, and UPDATE, which isn't true
since version 4.0.something.
Can anyone verify if the MERGE tables is still in gamma? We occassionally
have
from perror
143 = Conflicting table definition between MERGE and mapped table
On Sunday, Sep 22, 2002, at 18:36 America/Anchorage, David Herring
wrote:
Hello,
I get the following error when trying to access a table created of
TYPE=MERGE
mysql describe yy;
ERROR 1016: Can't open
Does your master table have a list of table names and the table's
characteristics? How is the search called?
currently i have a master table called files, the primary key is id and
the data tables are called filedata1 filedata2, etc.
where 1 and 2 correspond to the file id. Each of the
I have these two tables;
mysql describe tblClass11;
+--+---+--+-+-++
| Field| Type | Null | Key | Default | Extra |
+--+---+--+-+-++
| ID | int(11)
At 15:29 -0500 5/6/02, Jay Blanchard wrote:
I have these two tables;
mysql describe tblClass11;
+--+---+--+-+-++
| Field| Type | Null | Key | Default | Extra |
[snip]
Then I attempt to query;mysql select count(*) from tblCross1;
ERROR 1016: Can't open file: 'tblCross1.MRG'. (errno: 143)
perror 143
143 = Conflicting table definition between MERGE and mapped table
Can anyone help with this?
Drop the MERGE table, then try creating it with all the columns
At 15:44 -0500 5/6/02, Jay Blanchard wrote:
[snip]
Then I attempt to query;mysql select count(*) from tblCross1;
ERROR 1016: Can't open file: 'tblCross1.MRG'. (errno: 143)
perror 143
143 = Conflicting table definition between MERGE and mapped table
Can anyone help with this?
Drop the MERGE
I have been playing around with merge tables. You MUST have the columns and
indexes in the same order.
Eg. Do
SHOW INDEX FROM real_table;
SHOW INDEX FROM merge_table;
If the Column_name order is different you will get either no records or a
bunch of null records when you select on a column
Withers; Mysql-List
Subject: Re: MERGE TABLES
I have been playing around with merge tables. You MUST have the columns
and
indexes in the same order.
Eg. Do
SHOW INDEX FROM real_table;
SHOW INDEX FROM merge_table;
If the Column_name order is different you will get either no records or
a
bunch
PROTECTED]] On
Behalf Of Adams, Bill TQO
Sent: Thursday, August 30, 2001 1:11 PM
To: Sergei Golubchik
Cc: Johnny Withers; Mysql-List
Subject: Re: MERGE TABLES
I have been playing around with merge tables.
You MUST have the columns
and
indexes in the same order.
Eg. Do
SHOW INDEX FROM
Hi!
On Aug 29, Johnny Withers wrote:
I'm not sure if this is a bug or if this is the way MERGE TABLES works
in MySQL.
It seems that if I have an INDEX in a field (id for instance), and I try
to
SELECT using a WHERE id=NUMBER, it will fail, even though that NUMBER is
a
valid id. ID is an
Hi,
Ok, the first bug (incorrect COUNT, etc. for MERGE and individual tables)
was fixed some time ago. Though, it is possible that you found another bug,
the probability is low.
I thought I might be encountering actual bugs in the code in my 3.23.32
version. I'd taken a look at the changelog
Hi!
On May 01, Basil Hussain wrote:
Hi,
Ok, the first bug (incorrect COUNT, etc. for MERGE and individual tables)
was fixed some time ago. Though, it is possible that you found another bug,
the probability is low.
I thought I might be encountering actual bugs in the code in my
Hi!
On Apr 30, Matthew Shaw wrote:
Hi,
The merge table created is called asic_cache. It has exactly the same
structure as above except there are no keys what so ever. My
understanding is that there is no need for keys on the merge
table as the table handler uses the keys on each
Hi,
Table handler for MERGE can use keys of underlying tables for
key lookups, but in fact it never will, as SQL optimizer will never ask
to. Specifying keys for MERGE table is for SQL optimizer to able to
chose the best way to execute your SELECTs. No real keys are created,
as MERGE
Hi!
On Apr 30, Basil Hussain wrote:
Hi,
Anyway, while we're on the subject, I seem to be having some trouble with my
indexes on MERGE tables. I posted a message a while ago, but no-one seems to
have noticed it...
Basically, if I create my MERGE table with indexes on the same columns as
Hi,
On Fri, Apr 20, 2001 at 10:47:57AM +0100, Basil Hussain wrote:
I think I may have come up against a slight niggling omission concerning
Merge tables. How does one find out what physical tables are mapped, other
than by looking at the contents of the .MRG file?
Surely this information
Hi,
I think I may have come up against a slight niggling omission concerning
Merge tables. How does one find out what physical tables are mapped, other
than by looking at the contents of the .MRG file?
Surely this information should be displayed either when you do SHOW TABLE
STATUS or by
Hi,
On Fri, Apr 20, 2001 at 01:41:15PM +0100, Basil Hussain wrote:
I think I may have come up against a slight niggling omission concerning
Merge tables. How does one find out what physical tables are mapped, other
than by looking at the contents of the .MRG file?
Surely this
46 matches
Mail list logo
