> 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
> 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
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2013-01-03 17:30:39|
|Subject: Re: pg_retainxlog for inclusion in 9.3?|
|Previous:||From: Robert Haas||Date: 2013-01-03 17:27:45|
|Subject: Re: Re: Proposal: Store "timestamptz" of database creation