| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kevin Hunter <hunteke(at)earlham(dot)edu>, Joao Ferreira <joao(dot)miguel(dot)c(dot)ferreira(at)gmail(dot)com>, Postgres General List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: automatic REINDEX-ing |
| Date: | 2008-08-14 01:37:18 |
| Message-ID: | 20080814013717.GH4672@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane escribió:
> Crash safety. The basic process in vacuum full is:
>
> * detect that there is room in a lower-numbered page to move the
> physically last tuple to.
>
> * put a copy of the last tuple there. Mark the last tuple itself
> as deleted by the VACUUM.
Hmm, I've seen people doing piecemeal table shrinking with no exclusive
locking by looking up the live tuples in the last page, doing no-op
UPDATEs until they moves those tuples to an earlier page with free
space, and then hoping that plain VACUUM will detect that this page is
empty and truncating it. I wonder if we could write some (semi-)
automatic way of doing this. The benefit is that the page ends up
truncated to a reasonable of pages, reducing bloat, without requiring
the table to be exclusive-locked.
The main problem with this approach is that it is fairly painful to deal
with CTID values. The operator support for them is pretty poor.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2008-08-14 01:55:33 | Re: Design decision advice |
| Previous Message | Tom Lane | 2008-08-14 01:27:37 | Re: In-place conversion of type bool |