Обсуждение: GSoC 2018 Project Ideas & Mentors - Last Call

Greetings!

I've gone through and cleaned up our GSoC 2018 Wiki page:

https://wiki.postgresql.org/wiki/GSoC_2018

Please review!  If you have any last-minute items, please add them!

We could use some more mentors!  If you would have some time over the
summer to help with mentoring a GSoC project (note that it could be one
of the ones listed, or it might be a student-proposed project), please
add your name to the list under "Mentors (2018)".

I'll be submitting PostgreSQL as an organization for GSoC 2018 soon and
look forward to having another great PostgreSQL GSoC!

Thanks!

Stephen

I can help with the Sorting project.

On Thu, Jan 18, 2018 at 10:29 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Greetings!
>
> I've gone through and cleaned up our GSoC 2018 Wiki page:
>
> https://wiki.postgresql.org/wiki/GSoC_2018
>
> Please review!  If you have any last-minute items, please add them!
>
> We could use some more mentors!  If you would have some time over the
> summer to help with mentoring a GSoC project (note that it could be one
> of the ones listed, or it might be a student-proposed project), please
> add your name to the list under "Mentors (2018)".
>
> I'll be submitting PostgreSQL as an organization for GSoC 2018 soon and
> look forward to having another great PostgreSQL GSoC!
>
> Thanks!
>
> Stephen



-- 
Regards,

Atri
l'apprenant

Greetings,

* Atri Sharma (atri.jiit@gmail.com) wrote:
> I can help with the Sorting project.

Great!  I've added you as a mentor.

Thanks!

Stephen

Stephen Frost wrote:
> Greetings!
> 
> I've gone through and cleaned up our GSoC 2018 Wiki page:
> 
> https://wiki.postgresql.org/wiki/GSoC_2018
> 
> Please review!  If you have any last-minute items, please add them!
>
> We could use some more mentors!

I'm staying away this time.  Last year I added myself specifically to
help array foreign keys, but that was given to someone else, and then I
got added to some SSI items that I had no idea about ("just a backup
mentor!" they told me) and I ended up having to study that whole thing,
couldn't give any useful advice anyway, and used up all the time I could
have used to help array foreign keys, which is now months late with
little prospect of me having time to see it to completion.  In the end,
I felt it was a waste of time and disappointment to all involved.  Not
even a t-shirt to brag about ...  sheesh ...

-- 
Álvaro Herrera

On Thu, Jan 18, 2018 at 10:29 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Greetings!
>
> I've gone through and cleaned up our GSoC 2018 Wiki page:
>
> https://wiki.postgresql.org/wiki/GSoC_2018
>
> Please review!  If you have any last-minute items, please add them!
>

How about adding a project to support Unique capability for the Hash
Index?  I have previously shared some ideas on how to implement it [1]
and I can further elaborate it if required, but I think some
discussion is required.  I think it will be a good project for a new
person and I can help in completing it once we decide on some
particular design.  Now, if the student can complete this in time and
have the bandwidth to do more, we can ask him to support multi-column
hash indexes and the idea described by Tom to implement the same in
one of his emails [2] sounds doable to me in a reasonable amount of
time.

[1] - https://www.postgresql.org/message-id/CAA4eK1%2Bf%3DKpUW3TOW0P9LUCA8xhFujcjKhEnYRtoaB83LSsSMg%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/7192.1506527843%40sss.pgh.pa.us

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Sun, Jan 21, 2018 at 9:02 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> How about adding a project to support Unique capability for the Hash
> Index?

Hmm, that seems pretty hard.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jan 22, 2018 at 7:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Jan 21, 2018 at 9:02 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> How about adding a project to support Unique capability for the Hash
>> Index?
>
> Hmm, that seems pretty hard.
>

Yeah, but I think here hard part is to decide the solution to achieve
it.   The problem is that for the hash index to ensure that there is
no duplicate entry we need to traverse the whole bucket chain and also
we need to ensure that only one backend should be allowed to perform
it.  The simplest way to ensure that is to take and retain an
exclusive lock on the primary bucket for the whole operation.  Now,
considering that for unique indexes there shouldn't be many overflows
buckets, retaining lock doesn't sound to be much problematic.  We can
even think of slightly different locking technique as well which is
that instead of always retaining the lock on the primary bucket, we
can keep the lock on the first bucket where we find the space to
insert the key and then proceed to find the entry again by taking an
exclusive lock on each overflow bucket one-by-one. Only one inserter
should win in this scheme, the others should find the entry inserted
by it and probably the concurrency won't also be bad.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com