From: | Gordon <gordon(dot)mcvey(at)ntlworld(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Determining weather a query fired a trigger |
Date: | 2008-04-08 14:03:07 |
Message-ID: | c3704b41-1160-4237-9405-8dba0200f965@x41g2000hsb.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm adding full text search to a CMS project after we upgraded to 8.3
of Postgres. I'd like to do a bit of testing before deploying it.
I added columns to the pertinent tables for storing tsvectors, and was
looking at my query code to update it so these columns get updated
where appropriate when I discovered triggers as a solution to let this
all happen in a way that's completely invisible and will require no
rewriting of the existing queries. I set up triggers to fire on
insert or update to do the job and it all seems to work fine.
But I do have one concern regarding performance. The tsvector only
needs to be updated if the title, summary, or keywords fields have
changed. If they are the same after an update then there is no need
to run them. Doing so would only cause a new tsvector to be generated
when it wasn't necessary.
So what I want to know is, is there a way to tell if executing a query
caused a trigger to fire? I don't need anything fancy like notify
and listen, I just want to see what the database is doing for testing
purposes. For example by looking at the logs and seeing what activity
was caused by a given query. Does this stuff get logged?
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-04-08 14:06:29 | Re: Postgresql Conferences/events in Europe? |
Previous Message | Martijn van Oosterhout | 2008-04-08 13:53:57 | Re: Functions and transactions |