> 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
--
