Re: Partitioning and triggers

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

In response to

Responses

Browse pgsql-general by date

  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