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 <robertmh...@gmail.com> > On Fri, Apr 9, 2010 at 9:10 AM, Necati Batur <necatiba...@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 >
