Hello,
Does anyone have insight into this?
Thanks
-Zardosht
On Sat, Dec 7, 2013 at 8:51 AM, Zardosht Kasheff wrote:
> Hello all,
>
> I've noticed a scenario with index condition pushdown (ICP) in MariaDB
> that leads to really bad performance in TokuDB. I don't know if i
Hello all,
I've noticed a scenario with index condition pushdown (ICP) in MariaDB
that leads to really bad performance in TokuDB. I don't know if it is
a bug in ICP or if TokuDB is misusing/misunderstanding the API.
Here is the problem. Suppose we run the following query on the following schema:
I've worked on the TokuDB storage engine for quite a while now. I have
had many experiences over the years, so I guess it's hard to know
where to begin. I guess I will start small, and if the conversation
evolves, I can contribute more thoughts. I think the current API is
really good, as evidenced
+1 on the optimizer tracing. I have found it useful. We've had a
couple of instances where we looked at where an InnoDB query plan and
TokuDB query plan diverge for some query, and it showed us bugs in our
engine.
Just my $.02.
-Zardosht
On Mon, Jun 17, 2013 at 10:37 PM, Igor Babaev wrote:
> On
t; On Apr 26, Zardosht Kasheff wrote:
>> Hello all,
>>
>> Under what circumstances can a table be created with
>> MYSQL_TYPE_DECIMAL as being one of the columns? I thought
>> MYSQL_TYPE_DECIMAL was deprecated pre 5.1. I thought all new tables
>> use MYSQL_TYPE_
Hello all,
Under what circumstances can a table be created with
MYSQL_TYPE_DECIMAL as being one of the columns? I thought
MYSQL_TYPE_DECIMAL was deprecated pre 5.1. I thought all new tables
use MYSQL_TYPE_NEWDECIMAL.
We have a user reporting a table he wants to alter has that type.
However, when
Hello all,
I am encouraged to see this. I thought I would pass this along from
our testing. Near the end of releasing TokuDB v7, we tested 3.1.0,
3.2.0, 3.3.0, and 3.3.1. Performance and stability was the same on
all for tokudb.
So jemalloc 3.1 sounds fine for us.
-Zardosht
On Wed, Apr 24, 201
What you say is accurate. I have fixed this issue in our engine, but I
just wanted to make you aware of it.
On Mon, Mar 11, 2013 at 4:56 PM, Sergei Petrunia wrote:
> Hi Zardosht,
>
> On Thu, Mar 07, 2013 at 11:08:01PM -0500, Zardosht Kasheff wrote:
>> I have found an interesting i
Hello,
I have found an interesting issue with index condition pushdown. I do
not know if it is a bug, or if I am misusing the feature.
I have found that in one scenario, when performing a join, an index
condition is pushed down, but because handler->end_range is not set,
handler_index_cond_check
wrote:
> Zardosht Kasheff writes:
>
>> Reading the email, I think this is what is happening. You depend on
>> commit_ordered to order the transactions in the engine, and when the
>> binary log is going to rotate, you call commit_checkpoint_request on
>> the last transacti
, 2013 at 7:37 AM, Zardosht Kasheff wrote:
> Kristian, thank you for the detailed reply. My MariaDB 5.5 questions
> have been answered. So in this email, I will move on and explain a bit
> what commit does in TokuDB during commit. In another email, I will
> continue discussion on 10.0.
&
27;t just regrab the lock on the same thread), write to the
recovery log, then perform everything else under commit, then release
the read lock. It can probably be done, but it is messy. If
unnecessary, I prefer to not do it.
On Thu, Feb 21, 2013 at 5:42 AM, Kristian Nielsen
wrote:
> Zardosht Ka
Hello all,
I am investigating what our storage engine, TokuDB, needs to do to
achieve its best performance in MariaDB 5.5 with respect to preparing
and committing transactions, and with respect to binary logging.
As I understand, group commit has been added to the binary log in
Maria 5.3, and is
, if we happen to
accidentally not filter a row, MySQL will still behave correctly.
On Fri, Feb 15, 2013 at 8:28 PM, Sergei Petrunia wrote:
> On Thu, Feb 14, 2013 at 02:24:57PM -0500, Zardosht Kasheff wrote:
>> Also, can somebody please explain how handler_index_cond_check checks
>> i
}
int ha_maria::multi_range_read_explain_info(uint mrr_mode, char *str,
size_t size)
{
return ds_mrr.dsmrr_explain_info(mrr_mode, str, size);
}
On Fri, Feb 15, 2013 at 5:17 PM, Igor Babaev wrote:
> On 02/15/2013 04:17 AM, Zardosht Kasheff wrote:
>
Hello all,
Is there anything to implementing multi range read for storage
engines? Or is there a default implementation that is likely good
enough.
Also, is there anything one can read to understand how the feature
works and its benefits?
Thanks
-Zardosht
___
Also, can somebody please explain how handler_index_cond_check checks
index conditions? The key function seems to be item->val_int. How does
this get each value and check check conditions?
On Thu, Feb 14, 2013 at 11:31 AM, Zardosht Kasheff wrote:
> Hello Sergei,
>
> Thanks for the fe
2PM -0500, Zardosht Kasheff wrote:
>> Is there any documentation for what a storage engine needs to do to
>> implement index condition pushdown in MariaDB 5.5? I see some related
>> things, such as handler_index_cond_check, HA_DO_INDEX_COND_PUSHDOWN,
>> and idx_cond_push, but
Hello,
Is there any documentation for what a storage engine needs to do to
implement index condition pushdown in MariaDB 5.5? I see some related
things, such as handler_index_cond_check, HA_DO_INDEX_COND_PUSHDOWN,
and idx_cond_push, but I don't understand how these all interact with
each other.
T
Is there something similar in MariaDB?
-- Forwarded message --
From: Øystein Grøvlen
Date: Tue, Feb 12, 2013 at 9:11 AM
Subject: Re: debugging how query plans are made
To: Zardosht Kasheff
Cc: "intern...@lists.mysql.com"
On 02/12/13 02:54 PM, Zardosht Kas
Stewart, thanks for the feedback. That this was simple for Drizzle is
encouraging to hear.
Is there a proposal somewhere for eliminating the need for fsyncs on a
slave? As I understand, MWL#164 still requires the fsync.
On Mon, Jan 28, 2013 at 8:38 PM, Vadim Tkachenko wrote:
> Stewart,
>
> I wou
Hello Kristian,
Thanks again for the reply. Inlining my thoughts.
On Mon, Jan 28, 2013 at 10:06 AM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> In this email, I will focus on (and hope to understand better) just
>> the problems with having the binary log be an In
e,
not two more times. Yes, this is more data written, but it is
sequential data being written, so hopefully the hit is not too bad.
Thoughts?
-Zardosht
On Mon, Jan 28, 2013 at 4:28 AM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> Instead of having the binary log be s
Another question, are old timestamp fields stored the way is used to be? as
a little endian integer? or are those now big-endian as well?
On Tue, Jan 15, 2013 at 2:32 PM, Sergei Golubchik wrote:
> Hi, Zardosht!
>
> On Jan 15, Zardosht Kasheff wrote:
> > Hello all,
> >
>
, 2013 at 2:32 PM, Sergei Golubchik wrote:
> Hi, Zardosht!
>
> On Jan 15, Zardosht Kasheff wrote:
> > Hello all,
> >
> > In MySQL/MariaDB 5.1, when a timestamp field was used as a key, we
> > used an integer compare to compare the fields. We assumed all integer
>
Hello all,
In MySQL/MariaDB 5.1, when a timestamp field was used as a key, we used an
integer compare to compare the fields. We assumed all integer fields
(including date, time, and timestamp) could use an integer comparison to
compare the fields, and that they were either 1, 2, 3, 4 or 8 bytes lo
So, users will hopefully have their data predominately
in one engine. If not, they suffer performance in this scenario.
Nothing anyone can do about it.
>
> Thoughts?
>
> - Kristian.
>
> Kristian Nielsen writes:
>
>> Zardosht Kasheff writes:
>>
>>> Thank yo
log is not enabled, then the slaves are not crash safe. Is my
understanding correct?
Thanks
-Zardosht
On Fri, Oct 19, 2012 at 7:36 AM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> What is that solution? Is the solution in MariaDB 5.5? Is there a way
>> for another e
What is that solution? Is the solution in MariaDB 5.5? Is there a way
for another engine to also have this solution?
Thanks
-Zardosht
On Fri, Oct 19, 2012 at 3:16 AM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> Does Maria 10.0 implement crash safe replication that
Hello,
Does Maria 10.0 implement crash safe replication that is found in
MySQL 5.6.7? If so, does this issue exist there?
Thanks
-Zardosht
-- Forwarded message --
From: Zardosht Kasheff
Date: Wed, Oct 17, 2012 at 8:59 AM
Subject: possible bug in MySQL 5.6.7-rc slave
nction.
>
> $ diff log.cc.orig log.cc
> 7424a7425,7426
>> if (thd_get_ha_data(thd, binlog_hton) == NULL)
>> thd->binlog_setup_trx_data();
>
> Is this correct?
>
> Is this sufficient?
>
> Thanks
> RIch Prohaska
>
> On Tue, Jun 5, 2012 at 10:14 AM, Za
Hello all,
We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?
-Zardosht
-- Forwarded message --
From: Rich Prohaska
Date: Mon, Jun 4, 2012 at 1:23 PM
Subject: crash in slave replication with XA transaction
To: intern...@lists.mysql.com
Hello,
We are
t;
> Would that work for you? I mean both 1 and 2 above.
>
> On May 01, Zardosht Kasheff wrote:
>>
>> Attached is a proposed patch of new handler APIs. The purpose of this
>> patch is to give storage engines more information about impending
>> range queries. The idea is if
Hello all,
After talking with Colin Charles last night, I have been encouraged to
send more patches for MariaDB. Here is a hopefully simple one that
benefits all storage engines.
Attached is a proposed patch of new handler APIs. The purpose of this
patch is to give storage engines more informatio
The issue that I see with this proposal is that if quick_records is
much much greater than best_records, then we may not want to set
best_key to nr even though this nr is a covering index.
On Thu, May 19, 2011 at 6:04 AM, Michael Widenius wrote:
>
> Hi!
>
>>>>>> &qu
be committed as well?
Thanks
-Zardosht
On Wed, May 18, 2011 at 12:25 PM, Michael Widenius wrote:
>
> Hi!
>
> Here comes the feedback, patch by patch.
>
> Those that are ok 'as such or with small modifications' I will add to
> the 5.3 tree at once.
>
>>>
are 5.3 beta and this should not take long anymore).
>
> I will now go trough all of your patches and do my best to review and
> if they look ok add them to 5.3 tree.
>
>>>>>> "Zardosht" == Zardosht Kasheff writes:
>
> Zardosht> Hello all,
> Zar
Hello all,
In continuing with the suggestion to provide patches (given at the
storage engine summit last friday), here is another one (last one for
tonight).
Our storage engine wanted to add the ability to return an error to the
user that states that the disk is full. To do so, we added, we added
Hello all,
Continuing with patch contributions (as encouraged at the storage
engine summit last Friday), here is a very simple patch we have to fix
MySQL bug 57430 (http://bugs.mysql.com/bug.php?id=57430).
The problem is described in the bug report we sent to MySQL. We think
this simple fix addre
Hello all,
First off, thanks for hosting the storage engine summit last Friday.
At the beginning of the day, I was encouraged to send the patches that
I had for MWL#113 to the MariaDB developers list, in hopes possibly
getting them into MariaDB 5.3. Here they are. They are patched off of
MariaDB
0 at 2:53 PM, Zardosht Kasheff wrote:
> Hello,
>
> I am wondering if we can resurrect this discussion. In summary, I have
> a patch that I think I can apply to 5.1, although I realize it is not
> the ideal solution. It is a solution that I could code that minimizes
> the risk of
Thank you to everybody for the clarification. We will fix our engine
to not set 0 for stats.records unless we are absolutely sure it is
empty.
-Zardosht
On Thu, Dec 9, 2010 at 7:52 AM, Sergei Golubchik wrote:
> Hi, Zardosht!
>
> On Dec 08, Zardosht Kasheff wrote:
>>
>> W
t;lie" to the optimizer
> that the count is exact, but then treat is an approximate value,
> you'll get the above wrong result for sure.
>
> If this is not the problem, then please post a reproducible example.
>
> Timour
>
>>
>> -Zardosht
>>
>
on-empty. Is this assumption wrong?
-Zardosht
On Wed, Dec 8, 2010 at 2:42 PM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> We have been working on testing our storage engine, TokuDB, against
>> MariaDB 5.2.3, and we have encountered a problem with partitioning
>>
Hello all,
We have been working on testing our storage engine, TokuDB, against
MariaDB 5.2.3, and we have encountered a problem with partitioning
that does not exist on MySQL 5.1, MySQL 5.5, and MariaDB 5.1.50. This
problem also does not exist with any other storage engine that we have
tried. It O
-Zardosht
On Fri, Oct 1, 2010 at 8:59 AM, Zardosht Kasheff wrote:
> I did it this way for two reasons:
> - I did not want to try to port partitioning's alter table changes.
> That was getting into a realm where I could easily mess up
> - I was concerned with implementing the bac
sht!
>
> First: please send questions like this to the list, not only to me.
> I wanted to discuss this with Sergey Petrunia and had to paste this on
> irc.
>
> Anyway,
>
> On Oct 22, Zardosht Kasheff wrote:
>> Hello Sergei,
>>
>> One of the problems w
ppen is for the default implementations of
the new interface to check for and support these flags.
-Zarodsht
On Fri, Oct 1, 2010 at 3:44 AM, Kristian Nielsen
wrote:
> Zardosht Kasheff writes:
>
>> That being said, I would love to hear feedback on this patch, and
>> would also like t
Percona maintained patches. That must
> have been a lot of work on their part. Maybe they won't spend as much
> time on it going forward now that there is Percona server.
>
> On Wed, Sep 22, 2010 at 11:27 PM, Kristian Nielsen
> wrote:
>> Zardosht Kasheff writes:
>>
&g
I have spent some of my spare time looking into this. It turns out
that MySQL Cluster already has this ability. They have the following
handler functions listed below. I spent a weekend trying to port MySQL
Cluster's alter table function (mysql_alter_table) over to 5.1.46.
The port that I did was
Hello all,
I saw the following on planet mysql today,
http://www.facebook.com/note.php?note_id=430801045932, and it got me
thinking. I remember at the 2010 storage engine summit, we discussed
having more types of alter table be done online. Here are the meeting
notes on that topic:
Smarter "ALTER
The function is different than mysql 5.1.46. I have not looked at mysql 5.1.47
Thanks
-Zardosht
On Thu, Jul 22, 2010 at 8:19 AM, Sergei Golubchik wrote:
> Hi, Zardosht!
>
> On Jul 06, Zardosht Kasheff wrote:
>>
>> Oops, it turns out the function signature is differen
Oops, it turns out the function signature is different from MySQL.
This tripped us up.
-Zardosht
On Tue, Jul 6, 2010 at 3:15 PM, Zardosht Kasheff wrote:
> Hello,
>
> First off, is this the right list to post questions about MariaDB's
> source code? If it is not, I apologize,
Hello,
First off, is this the right list to post questions about MariaDB's
source code? If it is not, I apologize, and can somebody please direct
me to the right alias? I could not find anything on MariaDB's website.
I have noticed the following behavior in MariaDB 5.1.47 with our
storage engine
54 matches
Mail list logo
