maria-developers team mailing list archive

[Henrik Ingo <henrik.ingo@xxxxxxxxxxxxx>]

Hi Kristian

Thanks for a good summary.

I think my main, high-level takeaways were:

I wasn't aware that even our optimizer work can be controlled by
variables. I get for new features, but there's also refactoring going
into 5.3. I guess we cannot guarantee 100% identical behavior with
MySQL?

One thing you didn't mention, but came up in this discussion as well
as many others: The one killer feature people will be looking to
MariaDB for will be the replication API, and promise of better
replication. (more throughput, synchronous multi-master and easier to
manage/failover). Subqueries will make MariaDB a better RDBMS, and
possible a better migration target from the old proprietary databases,
but replication is interesting to current install base - especially
high profile users like Percona customers.

On Wed, Apr 21, 2010 at 1:29 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> We discussed a lot around this for the subquery optimisations. This is a
> "scary feature", as it has the very real potential to change execution plans,
> occasionally for the worse.
>
> As Timour pointed out, there is for each new optimiser feature a server
> variable to enable/disable it. So we need to very clearly state in the release
> notes, under "upgrading to MariaDB x.y", that there are optimiser changes, and
> give the exact list of variable settings that will make the optimiser run in
> "MySQL 5.1 mode".
...

> 2. On a note related to stability, I think we need to carefully avoid the
> mistakes from the MySQL release model. Basically, we need to have regular
> releases (6-12 month cycles). This is all-important! Much more important than
> any single feature, however big. We must _never_ push a feature into a tree if
> it is not ready. Better make an empty release!
>
> So this means it is actually wrong to say that subqueries will be in MariaDB
> 5.3. That should not be the plan. The subqueries will be in the first release
> made after they are ready. Which maybe 5.3, may be something else.
>
> I think we very nearly made the same mistake with 5.2. We had a feature list,
> and while some of them were "rolling", we also had features that were decided
> in advance that they _must_ be pushed at a certain date. I strongly believe
> this is wrong. We should have made _all_ features rolling.

I think everyone *says* they agree with above. You're right that we
did drive 5.2 a bit differently. I think it is ok for us at MP to set
some goals for ourselves as a team, then push to achieve those goals.
But ultimately, if some feature is not ready in time (and even "in
time" can often be a flexible concept as needed) then it will be
dropped and considered for future releases.

Btw, in the hypothetical case that we have nothing at all ready for a
release, then there is no point in releasing every 6 months. So it is
still valid to think of the process from the opposite point of view
saying: This is the work we have in front of us now, we'll finish
this, then we have a new release.

Reading my own text below I guess I'm only saying that real life is
often more flexible than just being one or the other. But ultimately -
yes, we should do precisely what you describe.

>
> 3. The final point I took from the discussion was related to version
> numbering. We in the MariaDB team of course know that we rock, and that we
> will change the world tomorrow, or at least as soon as planes will take us
> back to Europe :-). But the reality is that for now, we are an appendix to
> MySQL with MariaDB 5.1 and 5.2.
>
> It thus can be argued that this should be reflected in the version numbering,
> to avoid confusion. Peter made the point that he would like to see MariaDB 5.1
> and 5.2 versioning be made so that it is clear that there is a base MySQL
> version plus some well-defined set of changes. (This is how XtraDB release
> numbering works).
>
> So we currently have MariaDB 5.1.44, which is equivalent to MySQL 5.1.44 plus
> some set of safe patches. But MariaDB 5.2.0 is actually the same, just with
> some additional, also safe patches.
>
> So rather than go to MariaDB 5.2, we could imagine something like this:
>
>    MariaDB 5.1.44-1       Current MariaDB 5.1.44
>    MariaDB 5.1.44-2       Current MariaDB 5.2.0
>    MariaDB 5.1.44-1.1     In case we need to do a bugfix for 5.1.44-1
>    MariaDB 5.1.46-1       Next time we merge MySQL 5.1.46 into MariaDB -1
>    MariaDB 5.1.46-2       Next time we merge MySQL 5.1.46 into MariaDB -2
>
> I need to think more before I fully make up my mind about these points one way
> or the other, but I think these are in any case interesting points to
> consider.

This was an interesting remark by Peter. While I understand the point,
and it is a valid point, I instinctively dislike the suggestions
above.

What we do for 5.1 is good. MariaDB 5.1.44 is based on MySQL 5.1.44.
This is very easy to understand and remember.

I do believe that having the same scheme for 5.2 is still an option:
MariaDB 5.2.44 would be based on MySQL 5.1.44 (this is called 5.2.0 in
reality). This is not as intuitive as it is for 5.1 series, but
cleaner than what you suggest above.

Con: this scheme will only work as long as MySQL keeps leaving holes
in their releases.

henrik
-- 
email: henrik.ingo@xxxxxxxxxxxxx
tel:   +358-40-5697354
www:   www.avoinelama.fi/~hingo
book:  www.openlife.cc