> [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 everythin
[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 th
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 2/12
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 in
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:
> >>
> >>even
[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 __.
So for every sensor, and every day, there is now a new table. So if I
have 20 sensors, every day I
"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 __.
>
> 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
> > > 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
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
"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 upward
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
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 Tue
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 .0
"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
> SH
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 http://dev.mysql.com/doc/refman/5.0/en/merge
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, Firebir
"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, Firebi
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 MR
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
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
(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 very
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 don'
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 exis
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 th
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
* [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
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 se
[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 d
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
>
>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 f
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
[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 c
At 15:29 -0500 5/6/02, Jay Blanchard wrote:
>I have these two tables;
>mysql> describe tblClass11;
>+--+---+--+-+-++
>| Field| Type | Null | Key | Default | Extra |
>+--+---+--+-+-
I have these two tables;
mysql> describe tblClass11;
+--+---+--+-+-++
| Field| Type | Null | Key | Default | Extra |
+--+---+--+-+-++
| ID | int(11)
a
> normal key instead of
> PIMARY will solve the problem.
>
> (Filter : MySQL,database,SQL,etc)
>
> -
> Johnny Withers
> [EMAIL PROTECTED]
> p. 601.853.0211
> c. 601.209.4985
>
>
> -----Original Message-
> From: [EMAIL PROTECTED] [mailto
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 real_table;
SHOW INDEX FROM merge_table;
If the Column_name order is different you will get either no
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 that
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. I
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
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 changel
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 colum
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 ha
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 indi
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
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
>> ST
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 informati
46 matches
Mail list logo
