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
(Alvaro Herrera <alvherre@commandprompt.com>)
|
| 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:Sure. Nobody is saying otherwise.
> 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.This issue is, as Greg says, far more complicated than you realize. I
> 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.
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: