| From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Jan Wieck" <wieck(at)hub(dot)org>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
| Date: | 2000-12-10 13:48:12 |
| Message-ID: | EKEJJICOHDIEMGPNIFIJOECEDBAA.Inoue@tpf.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-12-10 17:12:50 | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
| Previous Message | Tom Lane | 2000-12-09 23:58:01 | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mwaples | 2000-12-10 14:48:35 | plpgsql question |
| Previous Message | Hannu Krosing | 2000-12-10 12:25:46 | Re: OK, does anyone have any better ideas? |