INSERT DELAYED and logging

--00221504829b3788990496394491
Content-Type: text/plain; charset=ISO-8859-1

I'm adding a table to our site that logs all page loads. In the past, when
I built this, I used MyISAM and INSERT DELAYED. I went back to look at the
documentation to see if I should still do this, and saw this (taken from
http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):

Note that INSERT DELAYED is slower than a normal INSERT if the table is not
otherwise in use. There is also the additional overhead for the server to
handle a separate thread for each table for which there are delayed rows.
This means that you should use INSERT DELAYED only when you are really sure
that you need it.

Does that mean that I shouldn't use it if all I'm doing is INSERT
(essentially an append-only table), with only very occasional SELECTs? In
addition, the last time I took this approach for logging, it worked well
until the table got to 65M+ rows, when it would crash every now and then. I
know I can archive off the table on a per month/quarter basis as well.

Waynn

--00221504829b3788990496394491--

Re: INSERT DELAYED and logging

--001636c5bc0f5d1aab049639ea31
Content-Type: text/plain; charset=ISO-8859-1

Well, analyze if you need to create an excessive overhead into the MySQL
Server because a simple INSERT. What you must have a look is it:

- How much data this connection is delivering to MySQL's handlers?
- A word DELAYED in this case is making MySQL surfer?

Perhaps, you are sophisticating something that do not need it. Besides it,
analyzing your "log table", I imagine this table can be an Archive table
instead of MyISAM. Log tables or history tables can be controlled by Archive
Storage Engine to have more compressed data. Although, Archive Storage
Engine only supports SELECT and INSERT. Maybe, a good deal to you, get rid
of you INSERT DELAYED:


- ALTER TABLE ENGINE = ARCHIVE;


Best regards.
--
WB


2010/11/29 WLGades

> I'm adding a table to our site that logs all page loads. In the past, when
> I built this, I used MyISAM and INSERT DELAYED. I went back to look at the
> documentation to see if I should still do this, and saw this (taken from
> http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>
> Note that INSERT DELAYED is slower than a normal INSERT if the table is not
> otherwise in use. There is also the additional overhead for the server to
> handle a separate thread for each table for which there are delayed rows.
> This means that you should use INSERT DELAYED only when you are really sure
> that you need it.
>
> Does that mean that I shouldn't use it if all I'm doing is INSERT
> (essentially an append-only table), with only very occasional SELECTs? In
> addition, the last time I took this approach for logging, it worked well
> until the table got to 65M+ rows, when it would crash every now and then.
> I
> know I can archive off the table on a per month/quarter basis as well.
>
> Waynn
>

--001636c5bc0f5d1aab049639ea31--

Re: INSERT DELAYED and logging

--00032555136a545c3f04963f2a4c
Content-Type: text/plain; charset=ISO-8859-1

No, I think it's a good idea to do INSERT DELAYED here - it's only logging
application, and it's generally more important to not slow down the
application for that. It's only ever into a single table, so there's only
going to be a single delay thread for it anyway.

Archive tables are a good idea, agreed, but I suspect that inserts into that
are going to be slower than into regular MyISAM because of the compression,
so why not use that overhead to (slightly) speed up your end-user experience
instead ?

You can always partition the table based on the log date or whatever, if
your table risks getting too big.


On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi
wrote:

> Well, analyze if you need to create an excessive overhead into the MySQL
> Server because a simple INSERT. What you must have a look is it:
>
> - How much data this connection is delivering to MySQL's handlers?
> - A word DELAYED in this case is making MySQL surfer?
>
> Perhaps, you are sophisticating something that do not need it. Besides it,
> analyzing your "log table", I imagine this table can be an Archive table
> instead of MyISAM. Log tables or history tables can be controlled by
> Archive
> Storage Engine to have more compressed data. Although, Archive Storage
> Engine only supports SELECT and INSERT. Maybe, a good deal to you, get rid
> of you INSERT DELAYED:
>
>
> - ALTER TABLE ENGINE = ARCHIVE;
>
>
> Best regards.
> --
> WB
>
>
> 2010/11/29 WLGades
>
> > I'm adding a table to our site that logs all page loads. In the past,
> when
> > I built this, I used MyISAM and INSERT DELAYED. I went back to look at
> the
> > documentation to see if I should still do this, and saw this (taken from
> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
> >
> > Note that INSERT DELAYED is slower than a normal INSERT if the table is
> not
> > otherwise in use. There is also the additional overhead for the server to
> > handle a separate thread for each table for which there are delayed rows.
> > This means that you should use INSERT DELAYED only when you are really
> sure
> > that you need it.
> >
> > Does that mean that I shouldn't use it if all I'm doing is INSERT
> > (essentially an append-only table), with only very occasional SELECTs?
> In
> > addition, the last time I took this approach for logging, it worked well
> > until the table got to 65M+ rows, when it would crash every now and then.
> > I
> > know I can archive off the table on a per month/quarter basis as well.
> >
> > Waynn
> >
>



--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--00032555136a545c3f04963f2a4c--

Re: INSERT DELAYED and logging

--000325572a62d22e9b04964064b4
Content-Type: text/plain; charset=ISO-8859-1

What I'm confused by though, is this line.

"Note that INSERT DELAYED is slower than a normal INSERT if the table is not
otherwise in use." What's the definition of "in use"? Does a logging table
do that given that it's pretty much append-only/write-only?

Waynn

On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman wrote:

> No, I think it's a good idea to do INSERT DELAYED here - it's only logging
> application, and it's generally more important to not slow down the
> application for that. It's only ever into a single table, so there's only
> going to be a single delay thread for it anyway.
>
> Archive tables are a good idea, agreed, but I suspect that inserts into
> that are going to be slower than into regular MyISAM because of the
> compression, so why not use that overhead to (slightly) speed up your
> end-user experience instead ?
>
> You can always partition the table based on the log date or whatever, if
> your table risks getting too big.
>
>
>
> On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi > > wrote:
>
>> Well, analyze if you need to create an excessive overhead into the MySQL
>> Server because a simple INSERT. What you must have a look is it:
>>
>> - How much data this connection is delivering to MySQL's handlers?
>> - A word DELAYED in this case is making MySQL surfer?
>>
>> Perhaps, you are sophisticating something that do not need it. Besides it,
>> analyzing your "log table", I imagine this table can be an Archive table
>> instead of MyISAM. Log tables or history tables can be controlled by
>> Archive
>> Storage Engine to have more compressed data. Although, Archive Storage
>> Engine only supports SELECT and INSERT. Maybe, a good deal to you, get rid
>> of you INSERT DELAYED:
>>
>>
>> - ALTER TABLE ENGINE = ARCHIVE;
>>
>>
>> Best regards.
>> --
>> WB
>>
>>
>> 2010/11/29 WLGades
>>
>> > I'm adding a table to our site that logs all page loads. In the past,
>> when
>> > I built this, I used MyISAM and INSERT DELAYED. I went back to look at
>> the
>> > documentation to see if I should still do this, and saw this (taken from
>> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>> >
>> > Note that INSERT DELAYED is slower than a normal INSERT if the table is
>> not
>> > otherwise in use. There is also the additional overhead for the server
>> to
>> > handle a separate thread for each table for which there are delayed
>> rows.
>> > This means that you should use INSERT DELAYED only when you are really
>> sure
>> > that you need it.
>> >
>> > Does that mean that I shouldn't use it if all I'm doing is INSERT
>> > (essentially an append-only table), with only very occasional SELECTs?
>> In
>> > addition, the last time I took this approach for logging, it worked well
>> > until the table got to 65M+ rows, when it would crash every now and
>> then.
>> > I
>> > know I can archive off the table on a per month/quarter basis as well.
>> >
>> > Waynn
>> >
>>
>
>
>
> --
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
>

--000325572a62d22e9b04964064b4--

Re: INSERT DELAYED and logging

--000325550e5a5168ea04964199a4
Content-Type: text/plain; charset=ISO-8859-1

I would assume that it's slower because it gets put on the delay thread
anyway, and thus executes only whenever that thread gets some attention. I'm
not sure wether there are other influencing factors.

I should also think that "not in use" in this context means "not locked
against inserts", so the MyISAM insert-while-selecting at the end of a
continguous table may well apply.

No guarantees, though - I'm not that hot on this depth.


On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:

> What I'm confused by though, is this line.
>
> "Note that INSERT DELAYED is slower than a normal INSERT if the table is
> not
> otherwise in use." What's the definition of "in use"? Does a logging
> table
> do that given that it's pretty much append-only/write-only?
>
> Waynn
>
> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman > >wrote:
>
> > No, I think it's a good idea to do INSERT DELAYED here - it's only
> logging
> > application, and it's generally more important to not slow down the
> > application for that. It's only ever into a single table, so there's only
> > going to be a single delay thread for it anyway.
> >
> > Archive tables are a good idea, agreed, but I suspect that inserts into
> > that are going to be slower than into regular MyISAM because of the
> > compression, so why not use that overhead to (slightly) speed up your
> > end-user experience instead ?
> >
> > You can always partition the table based on the log date or whatever, if
> > your table risks getting too big.
> >
> >
> >
> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
> wagnerbianchijr@gmail.com
> > > wrote:
> >
> >> Well, analyze if you need to create an excessive overhead into the
> MySQL
> >> Server because a simple INSERT. What you must have a look is it:
> >>
> >> - How much data this connection is delivering to MySQL's handlers?
> >> - A word DELAYED in this case is making MySQL surfer?
> >>
> >> Perhaps, you are sophisticating something that do not need it. Besides
> it,
> >> analyzing your "log table", I imagine this table can be an Archive table
> >> instead of MyISAM. Log tables or history tables can be controlled by
> >> Archive
> >> Storage Engine to have more compressed data. Although, Archive Storage
> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you, get
> rid
> >> of you INSERT DELAYED:
> >>
> >>
> >> - ALTER TABLE ENGINE = ARCHIVE;
> >>
> >>
> >> Best regards.
> >> --
> >> WB
> >>
> >>
> >> 2010/11/29 WLGades
> >>
> >> > I'm adding a table to our site that logs all page loads. In the past,
> >> when
> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to look
> at
> >> the
> >> > documentation to see if I should still do this, and saw this (taken
> from
> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
> >> >
> >> > Note that INSERT DELAYED is slower than a normal INSERT if the table
> is
> >> not
> >> > otherwise in use. There is also the additional overhead for the server
> >> to
> >> > handle a separate thread for each table for which there are delayed
> >> rows.
> >> > This means that you should use INSERT DELAYED only when you are really
> >> sure
> >> > that you need it.
> >> >
> >> > Does that mean that I shouldn't use it if all I'm doing is INSERT
> >> > (essentially an append-only table), with only very occasional SELECTs?
> >> In
> >> > addition, the last time I took this approach for logging, it worked
> well
> >> > until the table got to 65M+ rows, when it would crash every now and
> >> then.
> >> > I
> >> > know I can archive off the table on a per month/quarter basis as well.
> >> >
> >> > Waynn
> >> >
> >>
> >
> >
> >
> > --
> > Bier met grenadyn
> > Is als mosterd by den wyn
> > Sy die't drinkt, is eene kwezel
> > Hy die't drinkt, is ras een ezel
> >
>



--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--000325550e5a5168ea04964199a4--

Re: INSERT DELAYED and logging

--001636c5b06f25cbd90496440f04
Content-Type: text/plain; charset=ISO-8859-1

Maybe, the table in use must be a table that is inside cache now - SHOW OPEN
TABLES, controlled by table_cache, I mean.

Well, if the amount of data trasactioned is too small as a simple INSERT,
you don't have to be worried, I suggest. If you partition the table, we must
a benchmark to know the performance relation of a INSERT and compress data
into Archive Storage Engine or the insertion data into a partitioned table.

Best regards.
--
WB


2010/11/30 Johan De Meersman

> I would assume that it's slower because it gets put on the delay thread
> anyway, and thus executes only whenever that thread gets some attention. I'm
> not sure wether there are other influencing factors.
>
> I should also think that "not in use" in this context means "not locked
> against inserts", so the MyISAM insert-while-selecting at the end of a
> continguous table may well apply.
>
> No guarantees, though - I'm not that hot on this depth.
>
>
>
> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:
>
>> What I'm confused by though, is this line.
>>
>> "Note that INSERT DELAYED is slower than a normal INSERT if the table is
>> not
>> otherwise in use." What's the definition of "in use"? Does a logging
>> table
>> do that given that it's pretty much append-only/write-only?
>>
>> Waynn
>>
>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman >> >wrote:
>>
>> > No, I think it's a good idea to do INSERT DELAYED here - it's only
>> logging
>> > application, and it's generally more important to not slow down the
>> > application for that. It's only ever into a single table, so there's
>> only
>> > going to be a single delay thread for it anyway.
>> >
>> > Archive tables are a good idea, agreed, but I suspect that inserts into
>> > that are going to be slower than into regular MyISAM because of the
>> > compression, so why not use that overhead to (slightly) speed up your
>> > end-user experience instead ?
>> >
>> > You can always partition the table based on the log date or whatever, if
>> > your table risks getting too big.
>> >
>> >
>> >
>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
>> wagnerbianchijr@gmail.com
>> > > wrote:
>> >
>> >> Well, analyze if you need to create an excessive overhead into the
>> MySQL
>> >> Server because a simple INSERT. What you must have a look is it:
>> >>
>> >> - How much data this connection is delivering to MySQL's handlers?
>> >> - A word DELAYED in this case is making MySQL surfer?
>> >>
>> >> Perhaps, you are sophisticating something that do not need it. Besides
>> it,
>> >> analyzing your "log table", I imagine this table can be an Archive
>> table
>> >> instead of MyISAM. Log tables or history tables can be controlled by
>> >> Archive
>> >> Storage Engine to have more compressed data. Although, Archive Storage
>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you, get
>> rid
>> >> of you INSERT DELAYED:
>> >>
>> >>
>> >> - ALTER TABLE ENGINE = ARCHIVE;
>> >>
>> >>
>> >> Best regards.
>> >> --
>> >> WB
>> >>
>> >>
>> >> 2010/11/29 WLGades
>> >>
>> >> > I'm adding a table to our site that logs all page loads. In the
>> past,
>> >> when
>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to look
>> at
>> >> the
>> >> > documentation to see if I should still do this, and saw this (taken
>> from
>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>> >> >
>> >> > Note that INSERT DELAYED is slower than a normal INSERT if the table
>> is
>> >> not
>> >> > otherwise in use. There is also the additional overhead for the
>> server
>> >> to
>> >> > handle a separate thread for each table for which there are delayed
>> >> rows.
>> >> > This means that you should use INSERT DELAYED only when you are
>> really
>> >> sure
>> >> > that you need it.
>> >> >
>> >> > Does that mean that I shouldn't use it if all I'm doing is INSERT
>> >> > (essentially an append-only table), with only very occasional
>> SELECTs?
>> >> In
>> >> > addition, the last time I took this approach for logging, it worked
>> well
>> >> > until the table got to 65M+ rows, when it would crash every now and
>> >> then.
>> >> > I
>> >> > know I can archive off the table on a per month/quarter basis as
>> well.
>> >> >
>> >> > Waynn
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Bier met grenadyn
>> > Is als mosterd by den wyn
>> > Sy die't drinkt, is eene kwezel
>> > Hy die't drinkt, is ras een ezel
>> >
>>
>
>
>
> --
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
>

--001636c5b06f25cbd90496440f04--

Re: INSERT DELAYED and logging

--001636c5a8a458b22604964676de
Content-Type: text/plain; charset=ISO-8859-1

Friends, I did a benchmark regarding to this subject.
Please, I am considering your comments.
=> http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-del ayed/

Best regards.
--
WB


2010/11/30 Wagner Bianchi

> Maybe, the table in use must be a table that is inside cache now - SHOW
> OPEN TABLES, controlled by table_cache, I mean.
>
> Well, if the amount of data trasactioned is too small as a simple INSERT,
> you don't have to be worried, I suggest. If you partition the table, we must
> a benchmark to know the performance relation of a INSERT and compress data
> into Archive Storage Engine or the insertion data into a partitioned table.
>
> Best regards.
> --
> WB
>
>
> 2010/11/30 Johan De Meersman
>
> I would assume that it's slower because it gets put on the delay thread
>> anyway, and thus executes only whenever that thread gets some attention. I'm
>> not sure wether there are other influencing factors.
>>
>> I should also think that "not in use" in this context means "not locked
>> against inserts", so the MyISAM insert-while-selecting at the end of a
>> continguous table may well apply.
>>
>> No guarantees, though - I'm not that hot on this depth.
>>
>>
>>
>> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:
>>
>>> What I'm confused by though, is this line.
>>>
>>> "Note that INSERT DELAYED is slower than a normal INSERT if the table is
>>> not
>>> otherwise in use." What's the definition of "in use"? Does a logging
>>> table
>>> do that given that it's pretty much append-only/write-only?
>>>
>>> Waynn
>>>
>>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman >>> >wrote:
>>>
>>> > No, I think it's a good idea to do INSERT DELAYED here - it's only
>>> logging
>>> > application, and it's generally more important to not slow down the
>>> > application for that. It's only ever into a single table, so there's
>>> only
>>> > going to be a single delay thread for it anyway.
>>> >
>>> > Archive tables are a good idea, agreed, but I suspect that inserts into
>>> > that are going to be slower than into regular MyISAM because of the
>>> > compression, so why not use that overhead to (slightly) speed up your
>>> > end-user experience instead ?
>>> >
>>> > You can always partition the table based on the log date or whatever,
>>> if
>>> > your table risks getting too big.
>>> >
>>> >
>>> >
>>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
>>> wagnerbianchijr@gmail.com
>>> > > wrote:
>>> >
>>> >> Well, analyze if you need to create an excessive overhead into the
>>> MySQL
>>> >> Server because a simple INSERT. What you must have a look is it:
>>> >>
>>> >> - How much data this connection is delivering to MySQL's handlers?
>>> >> - A word DELAYED in this case is making MySQL surfer?
>>> >>
>>> >> Perhaps, you are sophisticating something that do not need it. Besides
>>> it,
>>> >> analyzing your "log table", I imagine this table can be an Archive
>>> table
>>> >> instead of MyISAM. Log tables or history tables can be controlled by
>>> >> Archive
>>> >> Storage Engine to have more compressed data. Although, Archive Storage
>>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you, get
>>> rid
>>> >> of you INSERT DELAYED:
>>> >>
>>> >>
>>> >> - ALTER TABLE ENGINE = ARCHIVE;
>>> >>
>>> >>
>>> >> Best regards.
>>> >> --
>>> >> WB
>>> >>
>>> >>
>>> >> 2010/11/29 WLGades
>>> >>
>>> >> > I'm adding a table to our site that logs all page loads. In the
>>> past,
>>> >> when
>>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to look
>>> at
>>> >> the
>>> >> > documentation to see if I should still do this, and saw this (taken
>>> from
>>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>>> >> >
>>> >> > Note that INSERT DELAYED is slower than a normal INSERT if the table
>>> is
>>> >> not
>>> >> > otherwise in use. There is also the additional overhead for the
>>> server
>>> >> to
>>> >> > handle a separate thread for each table for which there are delayed
>>> >> rows.
>>> >> > This means that you should use INSERT DELAYED only when you are
>>> really
>>> >> sure
>>> >> > that you need it.
>>> >> >
>>> >> > Does that mean that I shouldn't use it if all I'm doing is INSERT
>>> >> > (essentially an append-only table), with only very occasional
>>> SELECTs?
>>> >> In
>>> >> > addition, the last time I took this approach for logging, it worked
>>> well
>>> >> > until the table got to 65M+ rows, when it would crash every now and
>>> >> then.
>>> >> > I
>>> >> > know I can archive off the table on a per month/quarter basis as
>>> well.
>>> >> >
>>> >> > Waynn
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Bier met grenadyn
>>> > Is als mosterd by den wyn
>>> > Sy die't drinkt, is eene kwezel
>>> > Hy die't drinkt, is ras een ezel
>>> >
>>>
>>
>>
>>
>> --
>> Bier met grenadyn
>> Is als mosterd by den wyn
>> Sy die't drinkt, is eene kwezel
>> Hy die't drinkt, is ras een ezel
>>
>
>

--001636c5a8a458b22604964676de--

Re: INSERT DELAYED and logging

--00032555136a70e465049646b75a
Content-Type: text/plain; charset=ISO-8859-1

Interesting, but I feel the difference is rather small - could you rerun
with, say, 50.000 queries ? Also, different concurrency levels (1, 100)
might be interesting to see.

Yes, I'm to lazy to do it myself, what did you think :-p

On Tue, Nov 30, 2010 at 4:01 PM, Wagner Bianchi
wrote:

> Friends, I did a benchmark regarding to this subject.
> Please, I am considering your comments.
> => http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-del ayed/
>
> Best regards.
> --
> WB
>
>
> 2010/11/30 Wagner Bianchi
>
> Maybe, the table in use must be a table that is inside cache now - SHOW
>> OPEN TABLES, controlled by table_cache, I mean.
>>
>> Well, if the amount of data trasactioned is too small as a simple INSERT,
>> you don't have to be worried, I suggest. If you partition the table, we must
>> a benchmark to know the performance relation of a INSERT and compress data
>> into Archive Storage Engine or the insertion data into a partitioned table.
>>
>> Best regards.
>> --
>> WB
>>
>>
>> 2010/11/30 Johan De Meersman
>>
>> I would assume that it's slower because it gets put on the delay thread
>>> anyway, and thus executes only whenever that thread gets some attention. I'm
>>> not sure wether there are other influencing factors.
>>>
>>> I should also think that "not in use" in this context means "not locked
>>> against inserts", so the MyISAM insert-while-selecting at the end of a
>>> continguous table may well apply.
>>>
>>> No guarantees, though - I'm not that hot on this depth.
>>>
>>>
>>>
>>> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:
>>>
>>>> What I'm confused by though, is this line.
>>>>
>>>> "Note that INSERT DELAYED is slower than a normal INSERT if the table is
>>>> not
>>>> otherwise in use." What's the definition of "in use"? Does a logging
>>>> table
>>>> do that given that it's pretty much append-only/write-only?
>>>>
>>>> Waynn
>>>>
>>>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman >>>> >wrote:
>>>>
>>>> > No, I think it's a good idea to do INSERT DELAYED here - it's only
>>>> logging
>>>> > application, and it's generally more important to not slow down the
>>>> > application for that. It's only ever into a single table, so there's
>>>> only
>>>> > going to be a single delay thread for it anyway.
>>>> >
>>>> > Archive tables are a good idea, agreed, but I suspect that inserts
>>>> into
>>>> > that are going to be slower than into regular MyISAM because of the
>>>> > compression, so why not use that overhead to (slightly) speed up your
>>>> > end-user experience instead ?
>>>> >
>>>> > You can always partition the table based on the log date or whatever,
>>>> if
>>>> > your table risks getting too big.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
>>>> wagnerbianchijr@gmail.com
>>>> > > wrote:
>>>> >
>>>> >> Well, analyze if you need to create an excessive overhead into the
>>>> MySQL
>>>> >> Server because a simple INSERT. What you must have a look is it:
>>>> >>
>>>> >> - How much data this connection is delivering to MySQL's handlers?
>>>> >> - A word DELAYED in this case is making MySQL surfer?
>>>> >>
>>>> >> Perhaps, you are sophisticating something that do not need it.
>>>> Besides it,
>>>> >> analyzing your "log table", I imagine this table can be an Archive
>>>> table
>>>> >> instead of MyISAM. Log tables or history tables can be controlled by
>>>> >> Archive
>>>> >> Storage Engine to have more compressed data. Although, Archive
>>>> Storage
>>>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you,
>>>> get rid
>>>> >> of you INSERT DELAYED:
>>>> >>
>>>> >>
>>>> >> - ALTER TABLE ENGINE = ARCHIVE;
>>>> >>
>>>> >>
>>>> >> Best regards.
>>>> >> --
>>>> >> WB
>>>> >>
>>>> >>
>>>> >> 2010/11/29 WLGades
>>>> >>
>>>> >> > I'm adding a table to our site that logs all page loads. In the
>>>> past,
>>>> >> when
>>>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to
>>>> look at
>>>> >> the
>>>> >> > documentation to see if I should still do this, and saw this (taken
>>>> from
>>>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>>>> >> >
>>>> >> > Note that INSERT DELAYED is slower than a normal INSERT if the
>>>> table is
>>>> >> not
>>>> >> > otherwise in use. There is also the additional overhead for the
>>>> server
>>>> >> to
>>>> >> > handle a separate thread for each table for which there are delayed
>>>> >> rows.
>>>> >> > This means that you should use INSERT DELAYED only when you are
>>>> really
>>>> >> sure
>>>> >> > that you need it.
>>>> >> >
>>>> >> > Does that mean that I shouldn't use it if all I'm doing is INSERT
>>>> >> > (essentially an append-only table), with only very occasional
>>>> SELECTs?
>>>> >> In
>>>> >> > addition, the last time I took this approach for logging, it worked
>>>> well
>>>> >> > until the table got to 65M+ rows, when it would crash every now and
>>>> >> then.
>>>> >> > I
>>>> >> > know I can archive off the table on a per month/quarter basis as
>>>> well.
>>>> >> >
>>>> >> > Waynn
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Bier met grenadyn
>>>> > Is als mosterd by den wyn
>>>> > Sy die't drinkt, is eene kwezel
>>>> > Hy die't drinkt, is ras een ezel
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Bier met grenadyn
>>> Is als mosterd by den wyn
>>> Sy die't drinkt, is eene kwezel
>>> Hy die't drinkt, is ras een ezel
>>>
>>
>>
>


--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--00032555136a70e465049646b75a--

Re: INSERT DELAYED and logging

--001636c5a9383d514b049648d8ad
Content-Type: text/plain; charset=ISO-8859-1

I'll provide it to, bear with me, pls...

Best regards.
--
WB


2010/11/30 Johan De Meersman

> Interesting, but I feel the difference is rather small - could you rerun
> with, say, 50.000 queries ? Also, different concurrency levels (1, 100)
> might be interesting to see.
>
> Yes, I'm to lazy to do it myself, what did you think :-p
>
>
> On Tue, Nov 30, 2010 at 4:01 PM, Wagner Bianchi > > wrote:
>
>> Friends, I did a benchmark regarding to this subject.
>> Please, I am considering your comments.
>> => http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-del ayed/
>>
>> Best regards.
>> --
>> WB
>>
>>
>> 2010/11/30 Wagner Bianchi
>>
>> Maybe, the table in use must be a table that is inside cache now - SHOW
>>> OPEN TABLES, controlled by table_cache, I mean.
>>>
>>> Well, if the amount of data trasactioned is too small as a simple INSERT,
>>> you don't have to be worried, I suggest. If you partition the table, we must
>>> a benchmark to know the performance relation of a INSERT and compress data
>>> into Archive Storage Engine or the insertion data into a partitioned table.
>>>
>>> Best regards.
>>> --
>>> WB
>>>
>>>
>>> 2010/11/30 Johan De Meersman
>>>
>>> I would assume that it's slower because it gets put on the delay thread
>>>> anyway, and thus executes only whenever that thread gets some attention. I'm
>>>> not sure wether there are other influencing factors.
>>>>
>>>> I should also think that "not in use" in this context means "not locked
>>>> against inserts", so the MyISAM insert-while-selecting at the end of a
>>>> continguous table may well apply.
>>>>
>>>> No guarantees, though - I'm not that hot on this depth.
>>>>
>>>>
>>>>
>>>> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:
>>>>
>>>>> What I'm confused by though, is this line.
>>>>>
>>>>> "Note that INSERT DELAYED is slower than a normal INSERT if the table
>>>>> is not
>>>>> otherwise in use." What's the definition of "in use"? Does a logging
>>>>> table
>>>>> do that given that it's pretty much append-only/write-only?
>>>>>
>>>>> Waynn
>>>>>
>>>>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman <
>>>>> vegivamp@tuxera.be>wrote:
>>>>>
>>>>> > No, I think it's a good idea to do INSERT DELAYED here - it's only
>>>>> logging
>>>>> > application, and it's generally more important to not slow down the
>>>>> > application for that. It's only ever into a single table, so there's
>>>>> only
>>>>> > going to be a single delay thread for it anyway.
>>>>> >
>>>>> > Archive tables are a good idea, agreed, but I suspect that inserts
>>>>> into
>>>>> > that are going to be slower than into regular MyISAM because of the
>>>>> > compression, so why not use that overhead to (slightly) speed up your
>>>>> > end-user experience instead ?
>>>>> >
>>>>> > You can always partition the table based on the log date or whatever,
>>>>> if
>>>>> > your table risks getting too big.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
>>>>> wagnerbianchijr@gmail.com
>>>>> > > wrote:
>>>>> >
>>>>> >> Well, analyze if you need to create an excessive overhead into the
>>>>> MySQL
>>>>> >> Server because a simple INSERT. What you must have a look is it:
>>>>> >>
>>>>> >> - How much data this connection is delivering to MySQL's handlers?
>>>>> >> - A word DELAYED in this case is making MySQL surfer?
>>>>> >>
>>>>> >> Perhaps, you are sophisticating something that do not need it.
>>>>> Besides it,
>>>>> >> analyzing your "log table", I imagine this table can be an Archive
>>>>> table
>>>>> >> instead of MyISAM. Log tables or history tables can be controlled by
>>>>> >> Archive
>>>>> >> Storage Engine to have more compressed data. Although, Archive
>>>>> Storage
>>>>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you,
>>>>> get rid
>>>>> >> of you INSERT DELAYED:
>>>>> >>
>>>>> >>
>>>>> >> - ALTER TABLE ENGINE = ARCHIVE;
>>>>> >>
>>>>> >>
>>>>> >> Best regards.
>>>>> >> --
>>>>> >> WB
>>>>> >>
>>>>> >>
>>>>> >> 2010/11/29 WLGades
>>>>> >>
>>>>> >> > I'm adding a table to our site that logs all page loads. In the
>>>>> past,
>>>>> >> when
>>>>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to
>>>>> look at
>>>>> >> the
>>>>> >> > documentation to see if I should still do this, and saw this
>>>>> (taken from
>>>>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
>>>>> >> >
>>>>> >> > Note that INSERT DELAYED is slower than a normal INSERT if the
>>>>> table is
>>>>> >> not
>>>>> >> > otherwise in use. There is also the additional overhead for the
>>>>> server
>>>>> >> to
>>>>> >> > handle a separate thread for each table for which there are
>>>>> delayed
>>>>> >> rows.
>>>>> >> > This means that you should use INSERT DELAYED only when you are
>>>>> really
>>>>> >> sure
>>>>> >> > that you need it.
>>>>> >> >
>>>>> >> > Does that mean that I shouldn't use it if all I'm doing is INSERT
>>>>> >> > (essentially an append-only table), with only very occasional
>>>>> SELECTs?
>>>>> >> In
>>>>> >> > addition, the last time I took this approach for logging, it
>>>>> worked well
>>>>> >> > until the table got to 65M+ rows, when it would crash every now
>>>>> and
>>>>> >> then.
>>>>> >> > I
>>>>> >> > know I can archive off the table on a per month/quarter basis as
>>>>> well.
>>>>> >> >
>>>>> >> > Waynn
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Bier met grenadyn
>>>>> > Is als mosterd by den wyn
>>>>> > Sy die't drinkt, is eene kwezel
>>>>> > Hy die't drinkt, is ras een ezel
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bier met grenadyn
>>>> Is als mosterd by den wyn
>>>> Sy die't drinkt, is eene kwezel
>>>> Hy die't drinkt, is ras een ezel
>>>>
>>>
>>>
>>
>
>
> --
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
>

--001636c5a9383d514b049648d8ad--

Re: INSERT DELAYED and logging

--0023547c9be1f10bc604980b4a6a
Content-Type: text/plain; charset=UTF-8

Hi.
I think if there are not some concurrency visitors, you should not use it.
Otherwise, just put it.
David Yeung, In China, Beijing.
My First Blog:http://yueliangdao0608.cublog.cn
My Second Blog:http://yueliangdao0608.blog.51cto.com
My Msn: yueliangdao0608@gmail.com



2010/12/1 Wagner Bianchi

> I'll provide it to, bear with me, pls...
>
> Best regards.
> --
> WB
>
>
> 2010/11/30 Johan De Meersman
>
> > Interesting, but I feel the difference is rather small - could you rerun
> > with, say, 50.000 queries ? Also, different concurrency levels (1, 100)
> > might be interesting to see.
> >
> > Yes, I'm to lazy to do it myself, what did you think :-p
> >
> >
> > On Tue, Nov 30, 2010 at 4:01 PM, Wagner Bianchi <
> wagnerbianchijr@gmail.com
> > > wrote:
> >
> >> Friends, I did a benchmark regarding to this subject.
> >> Please, I am considering your comments.
> >> => http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-del ayed/
> >>
> >> Best regards.
> >> --
> >> WB
> >>
> >>
> >> 2010/11/30 Wagner Bianchi
> >>
> >> Maybe, the table in use must be a table that is inside cache now - SHOW
> >>> OPEN TABLES, controlled by table_cache, I mean.
> >>>
> >>> Well, if the amount of data trasactioned is too small as a simple
> INSERT,
> >>> you don't have to be worried, I suggest. If you partition the table, we
> must
> >>> a benchmark to know the performance relation of a INSERT and compress
> data
> >>> into Archive Storage Engine or the insertion data into a partitioned
> table.
> >>>
> >>> Best regards.
> >>> --
> >>> WB
> >>>
> >>>
> >>> 2010/11/30 Johan De Meersman
> >>>
> >>> I would assume that it's slower because it gets put on the delay thread
> >>>> anyway, and thus executes only whenever that thread gets some
> attention. I'm
> >>>> not sure wether there are other influencing factors.
> >>>>
> >>>> I should also think that "not in use" in this context means "not
> locked
> >>>> against inserts", so the MyISAM insert-while-selecting at the end of a
> >>>> continguous table may well apply.
> >>>>
> >>>> No guarantees, though - I'm not that hot on this depth.
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote:
> >>>>
> >>>>> What I'm confused by though, is this line.
> >>>>>
> >>>>> "Note that INSERT DELAYED is slower than a normal INSERT if the table
> >>>>> is not
> >>>>> otherwise in use." What's the definition of "in use"? Does a
> logging
> >>>>> table
> >>>>> do that given that it's pretty much append-only/write-only?
> >>>>>
> >>>>> Waynn
> >>>>>
> >>>>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman <
> >>>>> vegivamp@tuxera.be>wrote:
> >>>>>
> >>>>> > No, I think it's a good idea to do INSERT DELAYED here - it's only
> >>>>> logging
> >>>>> > application, and it's generally more important to not slow down the
> >>>>> > application for that. It's only ever into a single table, so
> there's
> >>>>> only
> >>>>> > going to be a single delay thread for it anyway.
> >>>>> >
> >>>>> > Archive tables are a good idea, agreed, but I suspect that inserts
> >>>>> into
> >>>>> > that are going to be slower than into regular MyISAM because of the
> >>>>> > compression, so why not use that overhead to (slightly) speed up
> your
> >>>>> > end-user experience instead ?
> >>>>> >
> >>>>> > You can always partition the table based on the log date or
> whatever,
> >>>>> if
> >>>>> > your table risks getting too big.
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
> >>>>> wagnerbianchijr@gmail.com
> >>>>> > > wrote:
> >>>>> >
> >>>>> >> Well, analyze if you need to create an excessive overhead into
> the
> >>>>> MySQL
> >>>>> >> Server because a simple INSERT. What you must have a look is it:
> >>>>> >>
> >>>>> >> - How much data this connection is delivering to MySQL's
> handlers?
> >>>>> >> - A word DELAYED in this case is making MySQL surfer?
> >>>>> >>
> >>>>> >> Perhaps, you are sophisticating something that do not need it.
> >>>>> Besides it,
> >>>>> >> analyzing your "log table", I imagine this table can be an Archive
> >>>>> table
> >>>>> >> instead of MyISAM. Log tables or history tables can be controlled
> by
> >>>>> >> Archive
> >>>>> >> Storage Engine to have more compressed data. Although, Archive
> >>>>> Storage
> >>>>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to you,
> >>>>> get rid
> >>>>> >> of you INSERT DELAYED:
> >>>>> >>
> >>>>> >>
> >>>>> >> - ALTER TABLE ENGINE = ARCHIVE;
> >>>>> >>
> >>>>> >>
> >>>>> >> Best regards.
> >>>>> >> --
> >>>>> >> WB
> >>>>> >>
> >>>>> >>
> >>>>> >> 2010/11/29 WLGades
> >>>>> >>
> >>>>> >> > I'm adding a table to our site that logs all page loads. In the
> >>>>> past,
> >>>>> >> when
> >>>>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back to
> >>>>> look at
> >>>>> >> the
> >>>>> >> > documentation to see if I should still do this, and saw this
> >>>>> (taken from
> >>>>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
> >>>>> >> >
> >>>>> >> > Note that INSERT DELAYED is slower than a normal INSERT if the
> >>>>> table is
> >>>>> >> not
> >>>>> >> > otherwise in use. There is also the additional overhead for the
> >>>>> server
> >>>>> >> to
> >>>>> >> > handle a separate thread for each table for which there are
> >>>>> delayed
> >>>>> >> rows.
> >>>>> >> > This means that you should use INSERT DELAYED only when you are
> >>>>> really
> >>>>> >> sure
> >>>>> >> > that you need it.
> >>>>> >> >
> >>>>> >> > Does that mean that I shouldn't use it if all I'm doing is
> INSERT
> >>>>> >> > (essentially an append-only table), with only very occasional
> >>>>> SELECTs?
> >>>>> >> In
> >>>>> >> > addition, the last time I took this approach for logging, it
> >>>>> worked well
> >>>>> >> > until the table got to 65M+ rows, when it would crash every now
> >>>>> and
> >>>>> >> then.
> >>>>> >> > I
> >>>>> >> > know I can archive off the table on a per month/quarter basis as
> >>>>> well.
> >>>>> >> >
> >>>>> >> > Waynn
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > --
> >>>>> > Bier met grenadyn
> >>>>> > Is als mosterd by den wyn
> >>>>> > Sy die't drinkt, is eene kwezel
> >>>>> > Hy die't drinkt, is ras een ezel
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Bier met grenadyn
> >>>> Is als mosterd by den wyn
> >>>> Sy die't drinkt, is eene kwezel
> >>>> Hy die't drinkt, is ras een ezel
> >>>>
> >>>
> >>>
> >>
> >
> >
> > --
> > Bier met grenadyn
> > Is als mosterd by den wyn
> > Sy die't drinkt, is eene kwezel
> > Hy die't drinkt, is ras een ezel
> >
>

--0023547c9be1f10bc604980b4a6a--

Re: INSERT DELAYED and logging

--00163628516867718c049818b8ad
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

ÑîÌÎÌÎ
* Stop top posting.*
*
*
*thanks.*
*
*
On Thu, Dec 23, 2010 at 12:16 AM, ÑîÌÎÌÎ com> wrote:

> Hi.
> I think if there are not some concurrency visitors, you should not use i=
t.
> Otherwise, just put it.
> David Yeung, In China, Beijing.
> My First Blog:http://yueliangdao0608.cublog.cn
> My Second Blog:http://yueliangdao0608.blog.51cto.com
> My Msn: yueliangdao0608@gmail.com
>
>
>
> 2010/12/1 Wagner Bianchi
>
> > I'll provide it to, bear with me, pls...
> >
> > Best regards.
> > --
> > WB
> >
> >
> > 2010/11/30 Johan De Meersman
> >
> > > Interesting, but I feel the difference is rather small - could you
> rerun
> > > with, say, 50.000 queries ? Also, different concurrency levels (1, 10=
0)
> > > might be interesting to see.
> > >
> > > Yes, I'm to lazy to do it myself, what did you think :-p
> > >
> > >
> > > On Tue, Nov 30, 2010 at 4:01 PM, Wagner Bianchi <
> > wagnerbianchijr@gmail.com
> > > > wrote:
> > >
> > >> Friends, I did a benchmark regarding to this subject.
> > >> Please, I am considering your comments.
> > >> =3D> http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-del aye=
d/
> > >>
> > >> Best regards.
> > >> --
> > >> WB
> > >>
> > >>
> > >> 2010/11/30 Wagner Bianchi
> > >>
> > >> Maybe, the table in use must be a table that is inside cache now -
> SHOW
> > >>> OPEN TABLES, controlled by table_cache, I mean.
> > >>>
> > >>> Well, if the amount of data trasactioned is too small as a simple
> > INSERT,
> > >>> you don't have to be worried, I suggest. If you partition the table=
,
> we
> > must
> > >>> a benchmark to know the performance relation of a INSERT and compre=
ss
> > data
> > >>> into Archive Storage Engine or the insertion data into a partitione=
d
> > table.
> > >>>
> > >>> Best regards.
> > >>> --
> > >>> WB
> > >>>
> > >>>
> > >>> 2010/11/30 Johan De Meersman
> > >>>
> > >>> I would assume that it's slower because it gets put on the delay
> thread
> > >>>> anyway, and thus executes only whenever that thread gets some
> > attention. I'm
> > >>>> not sure wether there are other influencing factors.
> > >>>>
> > >>>> I should also think that "not in use" in this context means "not
> > locked
> > >>>> against inserts", so the MyISAM insert-while-selecting at the end =
of
> a
> > >>>> continguous table may well apply.
> > >>>>
> > >>>> No guarantees, though - I'm not that hot on this depth.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Nov 30, 2010 at 8:46 AM, WLGades wrote=
:
> > >>>>
> > >>>>> What I'm confused by though, is this line.
> > >>>>>
> > >>>>> "Note that INSERT DELAYED is slower than a normal INSERT if the
> table
> > >>>>> is not
> > >>>>> otherwise in use." What's the definition of "in use"? Does a
> > logging
> > >>>>> table
> > >>>>> do that given that it's pretty much append-only/write-only?
> > >>>>>
> > >>>>> Waynn
> > >>>>>
> > >>>>> On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman <
> > >>>>> vegivamp@tuxera.be>wrote:
> > >>>>>
> > >>>>> > No, I think it's a good idea to do INSERT DELAYED here - it's
> only
> > >>>>> logging
> > >>>>> > application, and it's generally more important to not slow down
> the
> > >>>>> > application for that. It's only ever into a single table, so
> > there's
> > >>>>> only
> > >>>>> > going to be a single delay thread for it anyway.
> > >>>>> >
> > >>>>> > Archive tables are a good idea, agreed, but I suspect that
> inserts
> > >>>>> into
> > >>>>> > that are going to be slower than into regular MyISAM because of
> the
> > >>>>> > compression, so why not use that overhead to (slightly) speed u=
p
> > your
> > >>>>> > end-user experience instead ?
> > >>>>> >
> > >>>>> > You can always partition the table based on the log date or
> > whatever,
> > >>>>> if
> > >>>>> > your table risks getting too big.
> > >>>>> >
> > >>>>> >
> > >>>>> >
> > >>>>> > On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi <
> > >>>>> wagnerbianchijr@gmail.com
> > >>>>> > > wrote:
> > >>>>> >
> > >>>>> >> Well, analyze if you need to create an excessive overhead int=
o
> > the
> > >>>>> MySQL
> > >>>>> >> Server because a simple INSERT. What you must have a look is i=
t:
> > >>>>> >>
> > >>>>> >> - How much data this connection is delivering to MySQL's
> > handlers?
> > >>>>> >> - A word DELAYED in this case is making MySQL surfer?
> > >>>>> >>
> > >>>>> >> Perhaps, you are sophisticating something that do not need it.
> > >>>>> Besides it,
> > >>>>> >> analyzing your "log table", I imagine this table can be an
> Archive
> > >>>>> table
> > >>>>> >> instead of MyISAM. Log tables or history tables can be
> controlled
> > by
> > >>>>> >> Archive
> > >>>>> >> Storage Engine to have more compressed data. Although, Archive
> > >>>>> Storage
> > >>>>> >> Engine only supports SELECT and INSERT. Maybe, a good deal to
> you,
> > >>>>> get rid
> > >>>>> >> of you INSERT DELAYED:
> > >>>>> >>
> > >>>>> >>
> > >>>>> >> - ALTER TABLE ENGINE =3D ARCHIVE;
> > >>>>> >>
> > >>>>> >>
> > >>>>> >> Best regards.
> > >>>>> >> --
> > >>>>> >> WB
> > >>>>> >>
> > >>>>> >>
> > >>>>> >> 2010/11/29 WLGades
> > >>>>> >>
> > >>>>> >> > I'm adding a table to our site that logs all page loads. In
> the
> > >>>>> past,
> > >>>>> >> when
> > >>>>> >> > I built this, I used MyISAM and INSERT DELAYED. I went back
> to
> > >>>>> look at
> > >>>>> >> the
> > >>>>> >> > documentation to see if I should still do this, and saw this
> > >>>>> (taken from
> > >>>>> >> > http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html):
> > >>>>> >> >
> > >>>>> >> > Note that INSERT DELAYED is slower than a normal INSERT if t=
he
> > >>>>> table is
> > >>>>> >> not
> > >>>>> >> > otherwise in use. There is also the additional overhead for
> the
> > >>>>> server
> > >>>>> >> to
> > >>>>> >> > handle a separate thread for each table for which there are
> > >>>>> delayed
> > >>>>> >> rows.
> > >>>>> >> > This means that you should use INSERT DELAYED only when you
> are
> > >>>>> really
> > >>>>> >> sure
> > >>>>> >> > that you need it.
> > >>>>> >> >
> > >>>>> >> > Does that mean that I shouldn't use it if all I'm doing is
> > INSERT
> > >>>>> >> > (essentially an append-only table), with only very occasiona=
l
> > >>>>> SELECTs?
> > >>>>> >> In
> > >>>>> >> > addition, the last time I took this approach for logging, it
> > >>>>> worked well
> > >>>>> >> > until the table got to 65M+ rows, when it would crash every
> now
> > >>>>> and
> > >>>>> >> then.
> > >>>>> >> > I
> > >>>>> >> > know I can archive off the table on a per month/quarter basi=
s
> as
> > >>>>> well.
> > >>>>> >> >
> > >>>>> >> > Waynn
> > >>>>> >> >
> > >>>>> >>
> > >>>>> >
> > >>>>> >
> > >>>>> >
> > >>>>> > --
> > >>>>> > Bier met grenadyn
> > >>>>> > Is als mosterd by den wyn
> > >>>>> > Sy die't drinkt, is eene kwezel
> > >>>>> > Hy die't drinkt, is ras een ezel
> > >>>>> >
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Bier met grenadyn
> > >>>> Is als mosterd by den wyn
> > >>>> Sy die't drinkt, is eene kwezel
> > >>>> Hy die't drinkt, is ras een ezel
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > Bier met grenadyn
> > > Is als mosterd by den wyn
> > > Sy die't drinkt, is eene kwezel
> > > Hy die't drinkt, is ras een ezel
> > >
> >
>



--=20


Infrastructure Team

OLX Inc.

Buenos Aires - Argentina
Phone : 54.11.4775.6696
Mobile : 54.911.50436059
Email: alejandrob@olx.com

--00163628516867718c049818b8ad--