Re: GSOC PostgreSQL partitioning issue - Mailing list pgsql-hackers

From Necati Batur
Subject Re: GSOC PostgreSQL partitioning issue
Date
Msg-id h2u7c3006191004090749y7e8ff1fezc0acebadc89e24bf@mail.gmail.com
Whole thread Raw
In response to Re: GSOC PostgreSQL partitioning issue  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: GSOC PostgreSQL partitioning issue
List pgsql-hackers
Hi,
All I want to contribute to the project a liitle. I do not claim that I can actually solve all the issues about partitioning.
Of course there are lots of ideas ,some looks pretty easy however, the distribution issue seems too attractive to me that I am dying to work on. 
I have checked the development stages and I know I am focused and I can do something really beneficail to the community too.
Thanks all for attention :),
PS: Even if I would not be selected for gsoc I would still contribute teh postgresql due to this communication :)

2010/4/9 Robert Haas <robertmhaas@gmail.com>
On Fri, Apr 9, 2010 at 9:10 AM, Necati Batur <necatibatur@gmail.com> wrote:
> I am new at open source project however in a user point of view I must
> confess that usability is a really though issue ,even if the performance of
> a database is crucial.

Sure.  Nobody is saying otherwise.

> As to my idea for improve postgresql is ;
> http://www.postgresql.org/docs/current/interactive/ddl-partitioning.html  in
> cavetaes section is mentioned that
> "The schemes shown here assume that the partition key column(s) of a row
> never change, or at least do not change enough to require it to move to
> another partition. An UPDATE that attempts to do that will fail because of
> the CHECK constraints. If you need to handle such cases, you can put
> suitable update triggers on the partition tables, but it makes management of
> the structure much more complicated."
> Fixing this issue will help to improve the usability of partitions since the
> users do not want to deal with low-level integrity issues such as CHECK
> constraint.
> Roughly, I can say that if we want to deal with this issue,the first
> operation would be writing a trigger to check if an update operation causes
> a transfer issue between partitions.Then, if it is inevitable the user
> should be prompted about they are doing. Warning the system or user would
> generallry causes more trouble this point we need to decide on possible
> fixing ways and give more details about which choise will cause in what
> results. Then, creating a temprory table before commiting something will
> hellp us to conrol completeness and correctness.
> I tried to give more details about what I want to do.If you anything should
> be fixed in my proposal please earn me.

This issue is, as Greg says, far more complicated than you realize.  I
would like to recommend again, as I did previously off-list, that you
pick an easier project.  Here again is the link to some ideas I wrote
up previously.

http://archives.postgresql.org/pgsql-hackers/2010-03/msg01034.php

If you insist on pursuing a problem that you don't really understand
and that is far larger than what you can tackle in one summer, then
you are not going to be successful.

...Robert

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: extended operator classes vs. type interfaces
Next
From: Yeb Havinga
Date:
Subject: Re: extended operator classes vs. type interfaces