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