Re: table partioning performance
| От | Steven Flatt |
|---|---|
| Тема | Re: table partioning performance |
| Дата | |
| Msg-id | 357fa7590701101339m53a4b12foc805ff0060be609b@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: table partioning performance ("Jim C. Nasby" <jim@nasby.net>) |
| Ответы |
Re: table partioning performance
|
| Список | pgsql-performance |
On 1/10/07, Jim C. Nasby <jim@nasby.net> wrote:
Except for the simplest partitioning cases, you'll be much better off
using a trigger on the parent table to direct inserts/updates/deletes to
the children. As a bonus, using a trigger makes it a lot more realistic
to deal with an update moving data between partitions.
In our application, data is never moved between partitions.
The problem I found with triggers is the non-robustness of the PLpgSQL record data type. For example, in an "on insert" trigger, I can't determine the fields of the NEW record unless I hard code the column names into the trigger. This makes it hard to write a generic trigger, which I can use for all our partitioned tables. It would have been somewhat of a pain to write a separate trigger for each of our partitioned tables.
For that and other reasons, we moved some of the insert logic up to the application level in our product.
Steve
В списке pgsql-performance по дате отправления: