SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-18-2008, 11:54 AM
| ||||
| ||||
 Re: Fwd: Updates on large tables are extremely slow 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly      |
|
04-18-2008, 11:54 AM
| |||
| |||
| 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 -- ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) |
|
04-18-2008, 11:54 AM
| |||
| |||
| Re: Updates on large tables are extremely slow Hi, At 19:22 13/06/2005, Yves Vindevogel wrote: >It can't be indexes on other tables, right ? It could be foreign keys from that table referencing other tables or foreign keys from other tables referencing that table, especially if you don't have the matching indexes... Jacques. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org |
|
04-18-2008, 11:54 AM
| ||||
| ||||
| 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" No, it's normal MVCC design... ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
Linear Mode
