----------------------------------------
> Date: Sat, 29 Dec 2012 23:45:06 -0500
> Subject: Re: [HACKERS] Writing Trigger Functions in C
> From: robertmhaas@gmail.com
> To: charlesrg@outlook.com
> CC: cbbrowne@gmail.com; pgsql-hackers@postgresql.org
>
> On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes <charlesrg@outlook.com> wrote:
> > And I had no performance improvements at all.
> > Took the same time as with the previous EXECUTE statement;
> >
> > I don't see what am I doing wrong.
>
> You might not be doing anything wrong. Triggers ARE slow.
>
> If you have "perf" on your system, you could use "perf top" or "perf
> record -a" to find out where the CPU time is going while you're doing
> stuff that fires this trigger. That might provide some clues about
> how to optimize. But it may be that you'll get a completely flat
> profile, or something that otherwise boils down to ... triggers are
> slow.
>
> In answer to your original question, there is a C language trigger in
> contrib/tcn. But, without some proof that the use of PL/pgsql is the
> problem, I don't know how far down that road it's worth going. It
> might be worth writing a C trigger that does nothing but return the
> original tuple, or even a PL/pgsql one. This obviously wouldn't
> accomplish anything as far as partitioning goes, but it would let you
> measure the overhead of calling a no-op trigger, which could be a
> useful thing to know.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
I've translated the trigger to C and performance had not increased, just like you guys said. I've created an article
withthe trigger and the metrics in case anyone becomes interested in the future
http://www.charlesrg.com/linux/71-postgresql-partitioning-the-database-the-fastest-way