---------------------------------------- > Date: Sat, 29 Dec 2012 23:45:06 -0500 > Subject: Re: [HACKERS] Writing Trigger Functions in C > From: robertmh...@gmail.com > To: charle...@outlook.com > CC: cbbro...@gmail.com; pgsql-hackers@postgresql.org > > 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
I've translated the trigger to C and performance had not increased, just like you guys said. I've created an article with the 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
