Re: GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: George Papadrosou <gpapadrosou(at)gmail(dot)com>
Cc: Mengxing Liu <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)cn>, kgrittn <kgrittn(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Date: 2017-03-15 01:39:35
Message-ID: 20170315013934.GO9812@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

George,

* George Papadrosou (gpapadrosou(at)gmail(dot)com) wrote:
> I understand your efforts and I am willing to back down. This is not the only project that appeals to me :)

Thank you very much for your willingness to adapt. :)

> Mr. Frost, Mr. Munro, thank you for your suggestions. I am now between the TOAST’ing slices and the predicate locking project. I am keen on the fact the “toasting” project is related to on-disk data structures so I will probably send you an email about that later today.

I don't recall seeing an email from you about this yet? My apologies if
I missed it. I have added Alexander Korotkov to the CC list as he was
also listed as a possible mentor for TOAST'ing in slices.

As it relates to TOAST'ing in slices, it would be good to think through
how we would represent and store the information about how a particular
object has been split up. Note that PostgreSQL is very extensible in
its type system and therefore we would need a way for new data types
which are added to the system to be able to define how data of that data
type is to be split and a way to store the information they need to
regarding such a split.

In particular, the PostGIS project adds multiple data types which are
variable in length and often end up TOAST'd because they are large
geospatial objects, anything we come up with for TOAST'ing in slices
will need to be something that the PostGIS project could leverage.

> In general, I would like to undertake a project interesting enough and important for Postgres. Also, I could take into account if you favor one over another, so please let me know. I understand that these projects should be strictly defined to fit in the GSOC period, however the potential for future improvements or challenges is what drives and motivates me.

We are certainly very interested in having you continue on and work with
the PostgreSQL community moving forward, though we do need to be sure to
scope the project goals within the GSOC requirements.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2017-03-15 01:43:50 Re: ANALYZE command progress checker
Previous Message Robert Haas 2017-03-15 01:21:05 Re: Partition-wise join for join between (declaratively) partitioned tables