Hi Hemant!

We've discussed this a bit internally and we strongly feel this project is unlikely to be a good candidate for GSOC because of the big ramp up time. There are quite a few moving parts starting with the parse tree and it is very likely that you will spend most of your time doing discovery within the codebase and run out of time for actually coding the project. It's very likely that you will be set-up for failure in this case.

There are a lot of other projects that you may be able to tackle instead that will give you some insight and hopefully make the optimizer task easier. I recommend you have a look at our JSON related tasks. Some of them are quite easy and there might be room to "merge" 2 projects into one, if you feel that one would be too easy for you. (JSON_NORMALIZE and JSON_EQUALS).


On Fri, 19 Mar 2021 at 18:08, Hemant Kumar Singh <hkssheroksher@gmail.com> wrote:

So, this is what Igor mentioned in MDEV-13648 thread:
For those of you who are preparing proposals for this project:
In your proposal you are expected to cover the following issues:
1. How to build the tree for the result of re-writing for a join expression with FULL OUTER JOIN.
(It's not trivial as the parser provides you only with one tree that can be easily transformed into a
tree either for LEFT OUTER JOIN or for RIGHT OUTER JOIN, but not for both and you need the
trees for two SELECTs, not just for one. You can get an idea how you could build the
tree for the second SELECT in sql_view.cc).
2. At what stage to do the re-writing: at the parser stage, at the beginning of the context analysis
stage (see JOIN::prepare or at the beginning of the optimization stage (see JOIN::optimizer).
3. How to handle embedded FULL OUTER JOINs.
4. How and when to check possible conversion to LEFT OUTER JOIN or RIGHT OUTER JOIN.
5. What adjustments must be done for different references to the tables used in the original join
expression with FULL OUTER JOIN that may occur outside of this expression.

So, if we stick to point 1&2 will it make it comparable to other projects? Ofcourse, I'll try to complete the rest too, but for defining the sub-task as of now; will this suffice?

Hemant Kumar Singh
On Mar 14 2021, at 5:25 pm, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Hemant!

On Mar 14, Hemant Kumar Singh wrote:
> Hi everyone,
> I am Hemant from Nepal, currently a Computer Science Junior at NIT
> Warangal, India willing to take part in GSoC 2021.
> I saw a major priority task "MDEV-13648- Add FULL OUTER JOIN to
> MariaDB" unresolved since gsoc 2019; but it's not listed in 2021 List
> of Ideas. So, I was just wondering whether I can contribute to this
> task for gsoc 2021. Can anyone confirm this?

Yes, you absolutely can, and it's great that you're looking beyond
what's listed on our "GSoC 2021" page of suggestions.

The thing is - GSoC rules were changed this year and there is less time
for coding than before. So in 2021 we offer smaller tasks that can
reasonably fit within the new GSoC format.

For MDEV-13648, I think, we need to define some subtask, so that if you
implement that, the project would be still a success, even if you won't
have time for the full MDEV-13648. So - totally possible, and it'd be
perfect if you'll manage to do it all. But to make it comparable with
other tasks we should define this intermediate milestone within

VP of MariaDB Server Engineering
and security@mariadb.org
Sent from Mailspring_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to     : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp