Re: GSOC PostgreSQL partitioning issue

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(at)gmail(dot)com>

> On Fri, Apr 9, 2010 at 9:10 AM, Necati Batur <necatibatur(at)gmail(dot)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
>