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

Re: tsvector_update_trigger performance?

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Chris St Denis <lists(at)on-track(dot)ca>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: tsvector_update_trigger performance?
Date: 2009-06-25 06:55:40
Message-ID: 8CFF6A2F-7D5D-4C4C-9734-E85884E32000@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-performance
Also consider on update triggers that you could want to run anyway

--  
dim

Le 25 juin 2009 à 07:45, Craig Ringer <craig(at)postnewspapers(dot)com(dot)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
>

In response to

pgsql-performance by date

Next:From: Mike IvanovDate: 2009-06-25 18:18:31
Subject: Re: Implications of having large number of users
Previous:From: Craig RingerDate: 2009-06-25 05:45:19
Subject: Re: tsvector_update_trigger performance?

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