Re: [PERFORM] tsvector_update_trigger performance?
Also consider on update triggers that you could want to run anyway -- dim Le 25 juin 2009 à 07:45, Craig Ringer cr...@postnewspapers.com.au a écrit : On Wed, 2009-06-24 at 21:03 -0700, Chris St Denis wrote: This sounds like something that should just be on by default, not a trigger. Is there some reason it would waste the io of writing a new row to disk if nothing has changed? or is it just considered too much unnecessary overhead to compare them? I think the theory is that carefully written applications generally do not generate redundant updates in the first place. An application that avoids redundant updates should not have to pay the cost of redundant update detection and elimination. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] tsvector_update_trigger performance?
Oleg Bartunov wrote: On Wed, 24 Jun 2009, Chris St Denis wrote: Is tsvector_update_trigger() smart enough to not bother updating a tsvector if the text in that column has not changed? no, you should do check yourself. There are several examples in mailing lists. Or you could try using the supress_redundant_updates_trigger() function that has been included in 8.4 (should be easy to backport) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] tsvector_update_trigger performance?
Hi, Le 24 juin 09 à 18:29, Alvaro Herrera a écrit : Oleg Bartunov wrote: On Wed, 24 Jun 2009, Chris St Denis wrote: Is tsvector_update_trigger() smart enough to not bother updating a tsvector if the text in that column has not changed? no, you should do check yourself. There are several examples in mailing lists. Or you could try using the supress_redundant_updates_trigger() function that has been included in 8.4 (should be easy to backport) http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/min_update/ http://blog.tapoueh.org/projects.html#sec9 But it won't handle the case where some other random column has changed, but the UPDATE is not affecting the text indexed... -- dim -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] tsvector_update_trigger performance?
Dimitri Fontaine wrote: Hi, Le 24 juin 09 à 18:29, Alvaro Herrera a écrit : Oleg Bartunov wrote: On Wed, 24 Jun 2009, Chris St Denis wrote: Is tsvector_update_trigger() smart enough to not bother updating a tsvector if the text in that column has not changed? no, you should do check yourself. There are several examples in mailing lists. Or you could try using the supress_redundant_updates_trigger() function that has been included in 8.4 (should be easy to backport) http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/min_update/ http://blog.tapoueh.org/projects.html#sec9 But it won't handle the case where some other random column has changed, but the UPDATE is not affecting the text indexed... Tho this looks useful for some things, it doesn't solve my specific problem any. But thanks for the suggestion anyway. This sounds like something that should just be on by default, not a trigger. Is there some reason it would waste the io of writing a new row to disk if nothing has changed? or is it just considered too much unnecessary overhead to compare them? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] tsvector_update_trigger performance?
On Wed, 2009-06-24 at 21:03 -0700, Chris St Denis wrote: This sounds like something that should just be on by default, not a trigger. Is there some reason it would waste the io of writing a new row to disk if nothing has changed? or is it just considered too much unnecessary overhead to compare them? I think the theory is that carefully written applications generally do not generate redundant updates in the first place. An application that avoids redundant updates should not have to pay the cost of redundant update detection and elimination. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
