On 05/07/2012 12:30 PM, Zhangzhigang wrote:
Thanks, i thought about this answer in the past, and i appreciate your reply.
How about the omelet?
What's your method?
--
RMA.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/m
" that aggregate data to make
"reports" more efficient. (I have seen 10x to 1000x performance improvement.)
Should we discuss this?
> -Original Message-
> From: Karen Abgarian [mailto:a...@apple.com]
> Sent: Monday, May 07, 2012 8:37 PM
> To: mysql@lists.mysql.c
ck James
Cc: mysql@lists.mysql.com
Subject: 回复：Why is creating indexes faster after inserting massive data rows?
James...
>* By doing all the indexes after building the table (or at least all the
>non-UNIQUE indexes), "sort merge" can be used. This technique had been highly
>
enchmark _*your*_ case.
>
> ** **
>
> *From:* Claudio Nanni [mailto:claudio.na...@gmail.com]
> *Sent:* Wednesday, May 09, 2012 8:34 AM
> *To:* Rick James
> *Cc:* Zhangzhigang; mysql@lists.mysql.com
> *Subject:* Re: 回复： Why is creating indexes faster after inserting massive
> data rows?
e will have to hit disk.
> If you are using normal disks, that is on the order of 125 rows per second
> that you can insert �C Terrible! Sortmerge is likely to average over 10,000.
>
>
>
> From: Zhangzhigang [mailto:zzgang_2...@yahoo.com.cn]
> Sent: Tuesday, May 08, 2012 9:13
rows per second that
you can insert – Terrible! Sortmerge is likely to average over 10,000.
From: Zhangzhigang [mailto:zzgang_2...@yahoo.com.cn]
Sent: Tuesday, May 08, 2012 9:13 PM
To: Rick James
Cc: mysql@lists.mysql.com
Subject: 回复： Why is creating indexes faster after inserting massive data
James...
>* By doing all the indexes after building the table (or at least all the
>non-UNIQUE indexes), "sort merge" can be used. This technique had been highly
>optimized over the past half-century, and is more efficient.
I have a question about "sort merge":
Why does it do the all "sort me
Oh... I thought that it uses it's own buffer cache as same as the InnoDB. I
have got a mistake for this, thanks!
发件人： Karen Abgarian
收件人： mysql@lists.mysql.com
发送日期： 2012年5月9日, 星期三, 上午 2:51
主题: Re: 回复： 回复： 回复： Why is creating indexes faster after inse
Hi,
If MyISAM tables were being written directly to disk, the MyISAM tables would
be so slow that nobody would ever use them.That's the cornerstone of their
performance, that the writes do not wait for the physical I/O to complete!
On May 8, 2012, at 3:07 AM, Johan De Meersman wrote:
>
Ok, thanks for your help.
发件人： Johan De Meersman
收件人： Zhangzhigang
抄送： mysql@lists.mysql.com; Karen Abgarian
发送日期： 2012年5月8日, 星期二, 下午 6:07
主题: Re: 回复： 回复： 回复： Why is creating indexes faster after inserting massive data
rows?
- Original Message
- Original Message -
> From: "Zhangzhigang"
>
> As i known, the mysql writes the data to disk directly but does not
> use the Os cache when the table is updating.
If it were to use the OS cache for reading but not writing, then the OS cache
would be inconsistent with the underlying file
- Original Message -
> From: "Zhangzhigang"
>
> The mysql does not use this approach what you said which is
> complicated.
>
> I agree with ohan De Meersman.
Umm... It's not a matter of who you agree with :-) Karen's technical detail is
quite correct; I merely presented a simplified pic
2012年5月8日, 星期二, 上午 1:30
> 主题: Re: 回复： Why is creating indexes faster after inserting massive data rows?
>
> Hi,
>
> A couple cents to this.
>
> There isn't really a million of block writes. The record gets added to the
> block, but that gets modified in OS cac
ysql does not use this approach what you said which is complicated.
>
> I agree with ohan De Meersman.
>
>
>
> 发件人： Karen Abgarian
> 收件人： mysql@lists.mysql.com
> 发送日期： 2012年5月8日, 星期二, 上午 1:30
> 主题: Re: 回复： Why is creating indexes fast
Karen...
The mysql does not use this approach what you said which is complicated.
I agree with ohan De Meersman.
发件人： Karen Abgarian
收件人： mysql@lists.mysql.com
发送日期： 2012年5月8日, 星期二, 上午 1:30
主题: Re: 回复： Why is creating indexes faster after inserting massive
e faster.
>
> Based on this discussion, you should note that "random" indexes, such as
> GUIDs, MD5s, etc, tend to
>
>
>> -Original Message-
>> From: Karen Abgarian [mailto:a...@apple.com]
>> Sent: Monday, May 07, 2012 10:31 AM
>> To: mysql@list
Hi,
A couple cents to this.
There isn't really a million of block writes. The record gets added to the
block, but that gets modified in OS cache if we assume MyISAM tables and in the
Innodb buffer if we assume InnoDB tables. In both cases, the actual writing
does not take place and does
ect: Re: 回复： Why is creating indexes faster after inserting
> massive data rows?
>
> - Original Message -
>
> > From: "Zhangzhigang"
>
> > Ok, Creating the index *after* the inserts, the index gets created in
> > a single operation.
> > But t
- Original Message -
> From: "Zhangzhigang"
> Ok, Creating the index *after* the inserts, the index gets created in
> a single operation.
> But the indexes has to be updating row by row after the data rows has
> all been inserted. Does it work in this way?
No, when you create an index on
发送日期： 2012年5月7日, 星期一, 下午 4:59
> 主题: Re: 回复： Why is creating indexes faster after inserting massive data
> rows?
>
> On 2012/05/07 10:53, Zhangzhigang wrote:
> > johan
> >> Plain and simple: the indices get updated after every insert statement,
> > whereas if y
Thanks, i thought about this answer in the past, and i appreciate your reply.
发件人： Alex Schaft
收件人： mysql@lists.mysql.com
发送日期： 2012年5月7日, 星期一, 下午 4:59
主题: Re: 回复： Why is creating indexes faster after inserting massive data rows?
On 2012/05/07 10:53
回复： Why is creating indexes faster after inserting massive data rows?
Creating the index in one time is one macro-sort operation,
updating the index at every row is doing the operation on and on again.
If you do not understand the difference I recommend you to read some basics
about sorting algori
Creating the index in one time is one macro-sort operation,
updating the index at every row is doing the operation on and on again.
If you do not understand the difference I recommend you to read some basics
about sorting algorithms,
very interesting read anyway.
Claudio
2012/5/7 Zhangzhigang
>
On 2012/05/07 10:53, Zhangzhigang wrote:
johan
Plain and simple: the indices get updated after every insert statement,
whereas if you only create the index *after* the inserts, the index gets
created in a single operation, which is a lot more efficient..
Ok, Creating the index *after* t
johan
>Plain and simple: the indices get updated after every insert statement,
whereas if you only create the index *after* the inserts, the index gets
created in a single operation, which is a lot more efficient..
Ok, Creating the index *after* the inserts, the index gets created in a sin
Version : Mysql 5.1
Engine : MyISAM.
The indexes are normal but neither primary key or unique key.
I should describe mysql question clearly.
When inserting massive data rows to table which need to be created indexes, i
can create indexes before inserting data rows, anther way is that i can i
26 matches
Mail list logo
