OK. This is reasonable. So why do not we convert our current Innodb and
execution plan items to status variables and do not get this functionality
to write them to the log
> Over time we will have more and more variables and I don't think it
> makes sense to log all changes to the slow log.
>
Hei!
> "Sergei" == Sergei Golubchik writes:
Sergei> Hi, Peter!
Sergei> On Jun 03, Peter Zaitsev wrote:
>>
>> What is about adding these items as per thread variables and making it
>> possible to specify which per thread variables increments for the
>> query are to be logged in the slow que
Hi, Peter!
On Jun 03, Peter Zaitsev wrote:
>
> What is about adding these items as per thread variables and making it
> possible to specify which per thread variables increments for the
> query are to be logged in the slow query log ?
Should be possible, yes.
Although I think it would be easier
Hi!
> "Peter" == Peter Zaitsev writes:
Peter> Hi,
Peter> What is about adding these items as per thread variables and making it
Peter> possible to specify which per thread variables increments for the query
Peter> are to be logged in the slow query log ?
Good idea.
Need to think a bit o
Hi,
What is about adding these items as per thread variables and making it
possible to specify which per thread variables increments for the query
are to be logged in the slow query log ?
I should highlight this information availability in the logs is very
important for our performance optim
Hi, Vadim!
On May 28, Vadim Tkachenko wrote:
>
> Yes, I understand this is not best implementation, however is there
> any other way to have per-thread statistics for plugin and then have
> access to it to write to slow-log ?
per-thread statistics - yes.
writing to the slow log, no, plugins ca
Sergei,
Yes, I understand this is not best implementation, however is there any
other way to have per-thread statistics for plugin and then have access
to it to write to slow-log ?
Correct implementation may require changes in plugin interface, but I am
open for recommendations.
Thanks!
Vadim
Hi, Vadim!
On May 27, Vadim Tkachenko wrote:
> Monty,
>
> I made merge proposal:
>
> https://code.launchpad.net/~maria-captains/maria/slow-extended-patch/+merge/6840
>
> You can find patch there.
Eh, I certainly hope it won't be merged in its current form.
I didn't look too far, but even the v
Monty,
I made merge proposal:
https://code.launchpad.net/~maria-captains/maria/slow-extended-patch/+merge/6840
You can find patch there.
Best,
Vadim
Michael Widenius wrote:
> Hi!
>
>> "Arjen" == Arjen Lentz writes:
>
> Arjen> Hi Vadim
> Arjen> On 28/05/2009, at 1:22 AM, Vadim Tkachenko
Hi!
> "Arjen" == Arjen Lentz writes:
Arjen> Hi Vadim
Arjen> On 28/05/2009, at 1:22 AM, Vadim Tkachenko wrote:
>> We already ported patch
>> http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch
>> (from list
>> http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_ki
Hi Vadim
On 28/05/2009, at 1:22 AM, Vadim Tkachenko wrote:
We already ported patch
http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch
(from list
http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches_can_be_considered_for_MariaDB_5.1
)
to 5.1, so it wil
Hi,
We already ported patch
http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch
(from list
http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches_can_be_considered_for_MariaDB_5.1
)
to 5.1, so it will be easy to include it into MariaDB.
I will propose mer
12 matches
Mail list logo
