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(dot)vindevogel(at)implements(dot)be>
> Date: Mon 13 Jun 2005 17:45:19 CEST
> To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(dot)vindevogel(at)implements(dot)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
--