On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes <charle...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
