| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Chris St Denis <lists(at)on-track(dot)ca> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: tsvector_update_trigger performance? |
| Date: | 2009-06-25 05:45:19 |
| Message-ID: | 1245908719.19608.4.camel@tillium.localnet |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2009-06-25 06:55:40 | Re: tsvector_update_trigger performance? |
| Previous Message | Chris St Denis | 2009-06-25 04:03:08 | Re: tsvector_update_trigger performance? |