Re: GSOC PostgreSQL partitioning issue
От | Robert Haas |
---|---|
Тема | Re: GSOC PostgreSQL partitioning issue |
Дата | |
Msg-id | j2o603c8f071004090725r58601ffcv19175959b3747755@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GSOC PostgreSQL partitioning issue (Necati Batur <necatibatur@gmail.com>) |
Ответы |
Re: GSOC PostgreSQL partitioning issue
|
Список | pgsql-hackers |
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 по дате отправления: