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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: OK, does anyone have any better ideas?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)