Re: Vacuum now uses AccessShareLock for analyze
От | The Hermit Hacker |
---|---|
Тема | Re: Vacuum now uses AccessShareLock for analyze |
Дата | |
Msg-id | Pine.BSF.4.21.0005291337330.608-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: Vacuum now uses AccessShareLock for analyze (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Vacuum now uses AccessShareLock for analyze
|
Список | pgsql-hackers |
On Mon, 29 May 2000, Bruce Momjian wrote: > > On Mon, 29 May 2000, Bruce Momjian wrote: > > > > > I have changed vacuum so analyze now uses AccessShareLock. (Is this the > > > proper lock for analyze?) > > > > > > The code will now vacuum all requested relations. It will then analyze > > > each relation. This way, all the exclusive vacuum work is done first, > > > then analyze can continue with shared locks. > > > > hrmmm, here's a thought ... why not vacuum->analyze each relation in > > order? the 'exclusive lock' will prevent anyone from reading, so do a > > relation, release the lock to analyze that relation and let ppl access the > > database ... then do the next ... instead of doing an exclusive lock for > > the duration of the whole database ... > > No, each table is locked one at a time. We do all the single-table > locks first so the rest is all shared access. Does that make sense? its what I suspected, but my point was that if we did the ANALYZE for the relation right after the VACUUM for it, there would be a period of time where readers could come in and process ... think of it as a 'breather' before the next VACUUM starts, vs just jumping into the next ... Overall time for doing the vacuum shouldn't be any longer, but it would give gaps where readers could get in and out ... we're a relational database, so I imagine ppl are doing JOINs ... if RelationA is locked while ReaderA is trying to doign a JOIN between RA and RB, ReaderA is gonna be screwed ... if we did a quick ANALZE between RelationA and RelationB, then ReaderA would have a chance to do its processing while the ANALYZE is running, instead of having to wait for both RelationA and RelationB to be finished ...
В списке pgsql-hackers по дате отправления: