Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Mengxing Liu]

> > I agree that we can make skip list a general data structure.  But
> > can we use the fixed-level skip list as a Plan B? Or a quick attempt
> > before the general data structure ?
> > Because I am not familiar with shared memory structure and tricks
> > used in it, and I cannot estimate how much time it would take.
> 
> It's not really too bad for fixed allocation shared memory, and I
> can help with that.  If I thought it would save much I could see
> doing a prototype without generalization, but you would still have
> most of the same shared memory issues, since the structure *must*
> live in shared memory.
> 

Thank you. If there is no other problem, I will submit the proposal. 

--
Mengxing Liu










-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Kevin Grittner]

On Wed, Mar 29, 2017 at 11:17 PM, Mengxing Liu
 wrote:
> Thanks, I've updated the proposal. Just one issue:
> I agree that we can make skip list a general data structure.  But
> can we use the fixed-level skip list as a Plan B? Or a quick attempt
> before the general data structure ?
> Because I am not familiar with shared memory structure and tricks
> used in it, and I cannot estimate how much time it would take.

It's not really too bad for fixed allocation shared memory, and I
can help with that.  If I thought it would save much I could see
doing a prototype without generalization, but you would still have
most of the same shared memory issues, since the structure *must*
live in shared memory.

--
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Mengxing Liu]

Thanks, I've updated the proposal. Just one issue: 
I agree that we can make skip list a general data structure.  But can we use 
the fixed-level skip list as a Plan B? Or a quick attempt before the general 
data structure ? 
Because I am not familiar with shared memory structure and tricks used in it, 
and I cannot estimate how much time it would take. 


> -Original Messages-
> From: "Kevin Grittner" <kgri...@gmail.com>
> Sent Time: 2017-03-28 00:16:11 (Tuesday)
> To: "Mengxing Liu" <liu-m...@mails.tsinghua.edu.cn>
> Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate 
> O(N^2) scaling from rw-conflict tracking in serializable transactions
> 
> On Sat, Mar 25, 2017 at 9:24 PM, Mengxing Liu
> <liu-m...@mails.tsinghua.edu.cn> wrote:
> 
> > I've updated the proposal according to your comments.
> > But I am still wondering that can you review it for a double-check
> > to make sure I've made everything clear?
> 
> Additional comments added.
> 
> I'm afraid a few new issues came to mind reading it again.  (Nothing
> serious; just some points that could benefit from a little
> elaboration.)
> 
> --
> Kevin Grittner
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


--
Mengxing Liu










-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Kevin Grittner]

On Sat, Mar 25, 2017 at 9:24 PM, Mengxing Liu
 wrote:

> I've updated the proposal according to your comments.
> But I am still wondering that can you review it for a double-check
> to make sure I've made everything clear?

Additional comments added.

I'm afraid a few new issues came to mind reading it again.  (Nothing
serious; just some points that could benefit from a little
elaboration.)

--
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Mengxing Liu]

Thanks for your time. I've updated the proposal according to your comments. 
But I am still wondering that can you review it for a double-check to make sure 
I've made everything clear? 
You can read my replies for reference. 

> -Original Messages-
> From: "Kevin Grittner" <kgri...@gmail.com>
> Sent Time: 2017-03-25 04:53:36 (Saturday)
> To: "Mengxing Liu" <liu-m...@mails.tsinghua.edu.cn>
> Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate 
> O(N^2) scaling from rw-conflict tracking in serializable transactions
> 
> On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
> <liu-m...@mails.tsinghua.edu.cn> wrote:
> 
> > I've finished a draft proposal for "Eliminate O(N^2) scaling from
> > rw-conflict tracking in serializable transactions".
> 
> I've attached some comments to the document; let me know if they
> don't show up for you or you need clarification.
> 
> Overall, if the comments are addressed, I think it is great.
> 
> --
> Kevin Grittner


--
Mengxing Liu










-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Kevin Grittner]

On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
 wrote:

> I've finished a draft proposal for "Eliminate O(N^2) scaling from
> rw-conflict tracking in serializable transactions".

I've attached some comments to the document; let me know if they
don't show up for you or you need clarification.

Overall, if the comments are addressed, I think it is great.

--
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Kevin Grittner]

On Wed, Mar 22, 2017 at 2:24 AM, Mengxing Liu
 wrote:

> I've finished a draft proposal for "Eliminate O(N^2) scaling from
> rw-conflict tracking in serializable transactions".  You can find
> it from GSOC website or by the link below.
> https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing
>
> I was wondering if you have time to review the proposal and give me some 
> comments?

Will take a look and give you an initial review in a day or two.

--
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Mengxing Liu]

Hi, Kevin.

I've finished a draft proposal for "Eliminate O(N^2) scaling from rw-conflict 
tracking in serializable transactions".  You can find it from GSOC website or 
by the link below. 
https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing

I was wondering if you have time to review the proposal and give me some 
comments?  

> -Original Messages-
> From: "Kevin Grittner" <kgri...@gmail.com>
> Sent Time: 2017-03-17 21:57:18 (Friday)
> To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
> Cc: 
> Subject: [HACKERS] Guidelines for GSoC student proposals
> 
> I've found various sources that give hints about what a student
> proposal should look like, but nothing I could just give as a link,
> so I pulled together what I could find, tempered by my own ideas and
> opinions.  I suggest that we send the below, or something like it to
> each student who expresses interest in making a proposal, or who
> submits a proposal that doesn't meet the below guidelines.  Thoughts
> or suggestions for changes before we do?  Remember, time is short,
> so this cannot be a 200 message bike-shedding debate -- we just need
> to provide some sort of guidance to students in a timely way, with
> the timeline being:
> 
>   February 27 - March 20
> Potential student participants discuss application ideas with
> mentoring organizations
>   March 20 16:00 UTC
> Student application period opens
>   April 3 16:00 UTC
> Student application deadline
> 
> Each GSoC student proposal should be a PDF file of 6 to 8 pages.  In
> the end, Google will publish these documents on a web page, so the
> student should make each proposal something which they will be happy
> to have future potential employers review.
> 
> Some ideas for desirable content:
> 
>   - A resume or CV of the student, including any prior GSoC work
>   - Their reasons for wanting to participate
>   - What else they have planned for the summer, and what their time
> commitment to the GSoC work will be
>   - A clear statement that there will be no intellectual property
> problems with the work they will be doing -- that the PostgreSQL
> community will be able to use their work without encumbrances
> (e.g., there should be no agreements related to prior or
> ongoing work which might assign the rights to the work they do
> to someone else)
>   - A description of what they will do, and how
>   - Milestones with dates
>   - What they consider to be the test that they have successfully
> completed the project
> 
> Note that a student proposal is supposed to be far more detailed
> than the ideas for projects provided by the organization -- those
> are intended to be ideas for what the student might write up as a
> proposal, not ready-to-go proposal documents.
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


--
Mengxing Liu










-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Guidelines for GSoC student proposals

[Kevin Grittner]

I've found various sources that give hints about what a student
proposal should look like, but nothing I could just give as a link,
so I pulled together what I could find, tempered by my own ideas and
opinions.  I suggest that we send the below, or something like it to
each student who expresses interest in making a proposal, or who
submits a proposal that doesn't meet the below guidelines.  Thoughts
or suggestions for changes before we do?  Remember, time is short,
so this cannot be a 200 message bike-shedding debate -- we just need
to provide some sort of guidance to students in a timely way, with
the timeline being:

  February 27 - March 20
Potential student participants discuss application ideas with
mentoring organizations
  March 20 16:00 UTC
Student application period opens
  April 3 16:00 UTC
Student application deadline

Each GSoC student proposal should be a PDF file of 6 to 8 pages.  In
the end, Google will publish these documents on a web page, so the
student should make each proposal something which they will be happy
to have future potential employers review.

Some ideas for desirable content:

  - A resume or CV of the student, including any prior GSoC work
  - Their reasons for wanting to participate
  - What else they have planned for the summer, and what their time
commitment to the GSoC work will be
  - A clear statement that there will be no intellectual property
problems with the work they will be doing -- that the PostgreSQL
community will be able to use their work without encumbrances
(e.g., there should be no agreements related to prior or
ongoing work which might assign the rights to the work they do
to someone else)
  - A description of what they will do, and how
  - Milestones with dates
  - What they consider to be the test that they have successfully
completed the project

Note that a student proposal is supposed to be far more detailed
than the ideas for projects provided by the organization -- those
are intended to be ideas for what the student might write up as a
proposal, not ready-to-go proposal documents.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers