From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Edson Richter <edsonrichter(at)hotmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Partitioning and triggers |
Date: | 2013-11-17 20:45:33 |
Message-ID: | CAMkU=1yNBXM7Qo-9jmAB+nKx7A2w9j+k2RDekZzvPkqezo7NNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Nov 17, 2013 at 8:46 AM, Edson Richter <edsonrichter(at)hotmail(dot)com>wrote:
> Dear community,
>
> In documentation, when partitioning tables, it is said that "Optionally,
> define a trigger or rule to redirect data inserted into the master table to
> the appropriate partition."
> Is the trigger creation optional? I mean, partitioning will not work as
> expected if we don't have the trigger, right?
That depends on what you expect :)
> Or will PostgreSQL "decide automatically" which table to use?
> If the trigger is not there, when I add a row to "measurement" table (like
> in docs example), it will be phisically inserted into "measurement" table,
> not in the childs tables.
> Am I right in this understanding?
>
Yes. And if there is a constraint that blocks it from going into the
parent table, you will get an error. If you have the constraint but not
the trigger, that means it is the application's job to insert into the
correct partition. This can make sense as triggers have a lot of overhead,
whereas the application can usually do this with less overhead. Or you can
have neither the trigger nor the constraint, and have it go into the parent
table by design. Whether that is a good idea depends on why you are
partitioning.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Edson Richter | 2013-11-17 20:57:23 | Re: Partitioning and triggers |
Previous Message | Kevin Goess | 2013-11-17 17:53:05 | Re: simple query with radically different plan after 9.0 -> 9.2 upgrade |