RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
От | Hiroshi Inoue |
---|---|
Тема | RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJOECEDBAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > Hmm,is there any good reason to vacuum toast table in the > > transaction which was already internally committed by vacuum > > of the master table ? Is it possible under WAL ? > > It had better be possible under WAL, because vacuuming indexes is > done in essentially the same way: we clean the indexes *after* we > commit the master's tuple movements. > There's no command other than VACUUM which continues to access table/index after *commit*. We couldn't process significant procedures in such an already commiitted state, could we ? > Really, the TOAST table is being treated the same way we handle > indexes, and I think that's good. > If I recognize correctly,TOAST table is a table not an index and is little different from ordinary tables. VACUUM now vacuums 2 tables in a transaction for tables with TOAST columns. ^^^^^^^^^^^^^^^^^^ I don't think it's right and my question is simple. What's wrong with vacuuming master and the toast table in separate transactions ? Regrads. Hiroshi Inoue
В списке pgsql-hackers по дате отправления: