Skip site navigation (1) Skip section navigation (2)

Re: Writing Trigger Functions in C

From: Charles Gomes <charlesrg(at)outlook(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org"<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Writing Trigger Functions in C
Date: 2013-01-03 17:28:53
Message-ID: BLU002-W66CB5971D7BECD0995A6EAAB210@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Date: Sat, 29 Dec 2012 23:45:06 -0500
> Subject: Re: [HACKERS] Writing Trigger Functions in C
> From: robertmhaas(at)gmail(dot)com
> To: charlesrg(at)outlook(dot)com
> CC: cbbrowne(at)gmail(dot)com; pgsql-hackers(at)postgresql(dot)org
> On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes <charlesrg(at)outlook(dot)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:
> 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 		 	   		  

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-03 17:30:39
Subject: Re: pg_retainxlog for inclusion in 9.3?
Previous:From: Robert HaasDate: 2013-01-03 17:27:45
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group