Re: Updates on large tables are extremely slow

> Ok, if all 21 are affected, I can understand the problem.
> But allow me to say that this is a "functional error"

It's a choice between total throughput on a high load, high connection
basis (MVCC dramatically wins here), versus a single user, low load
scenario (MS Access is designed for this).

Believe me when I say that a lot of people have spent a lot of time
explicitly making the system work that way.

> On 13 Jun 2005, at 18:02, Richard Huxton wrote:
>
>         Yves Vindevogel wrote:
>                 I forgot cc
>                 Begin forwarded message:
>                         From: Yves Vindevogel
>                         <yves.vindevogel@implements.be>
>                         Date: Mon 13 Jun 2005 17:45:19 CEST
>                         To: Tom Lane <tgl@sss.pgh.pa.us>
>                         Subject: Re: [PERFORM] Updates on large tables
>                         are extremely slow
>
>                         Yes, but if I update one column, why should PG
>                         update 21 indexes ?
>                         There's only one index affected !
>
>         No - all 21 are affected. MVCC creates a new row on disk.
>
>         --
>           Richard Huxton
>           Archonet Ltd
>
>
> Met vriendelijke groeten,
> Bien à vous,
> Kind regards,
>
> Yves Vindevogel
> Implements
>
>
>
> ______________________________________________________________________
>
>
>
> Mail: yves.vindevogel@implements.be  - Mobile: +32 (478) 80 82 91
>
> Kempische Steenweg 206 - 3500 Hasselt - Tel-Fax: +32 (11) 43 55 76
>
> Web: http://www.implements.be
>
> First they ignore you.  Then they laugh at you.  Then they fight you.
> Then you win.
> Mahatma Ghandi.
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
--