Zardosht Kasheff writes:
> What I do not understand is this. Why does the following code at line
> 4734 of ha_partition.cc (at the bottom of this message) simply assume
> that if file->stats.records is 0, that it can blindly return
> HA_ERR_END_OF_FILE? I understand if file->ha_table_flags expose
Hi Monty,
here are the results comparing your string optimization patch with MariaDB 5.2
and sql-bench. I added the configuration used, a short summary, and a full
summary of the results.
I ran the test on our new machine "pitbull", a two socket hexa-core Intel
Xeon X5660 @ 2.80GHz with 23GB RAM
Our storage engine does not lie to the optimizer. We do not set the
HA_STATS_RECORDS_IS_EXACT flag. I do not know this code well enough to
understand how the relevant code in opt_sum.cc results in the
partition code I describe get executed.
What I do not understand is this. Why does the following
Zardosht,
I think we found out the problem. In ha_partition.cc, in the function
ha_partition::handle_ordered_index_scan, this code was added:
case partition_index_last:
/*
MyISAM engine can fail if we call index_last() when indexes disabled
that happens if the table
I think we found out the problem. In ha_partition.cc, in the function
ha_partition::handle_ordered_index_scan, this code was added:
case partition_index_last:
/*
MyISAM engine can fail if we call index_last() when indexes disabled
that happens if the table is empty.
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
> 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 t
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
[Cc:ing maria-developers@ as I want us to get into the habbit of discussing
more openly, hope that is ok]
MARK CALLAGHAN writes:
> I think that Mats identified the problem and then Vamsi did a
> reproduction of it.
> http://bugs.mysql.com/58787
Thanks for pointing me to this issue Mark!
I'm wo
8 matches
Mail list logo