Re: Resurrecting per-page cleaner for btree
От | Bruce Momjian |
---|---|
Тема | Re: Resurrecting per-page cleaner for btree |
Дата | |
Msg-id | 200607250014.k6P0Ejc01739@momjian.us обсуждение исходный текст |
Ответ на | Re: Resurrecting per-page cleaner for btree (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > > This is a revised patch originated by Junji TERAMOTO for HEAD. > > [BTree vacuum before page splitting] > > http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php > > I think we can resurrect his idea because we will scan btree pages > > at-atime now; the missing-restarting-point problem went away. > > Have I missed something? Comments welcome. > > I think the only serious objection to this would be that it'd mean that > tuples that should have an index entry might not have one. The current > form of VACUUM does not care, but people keep raising the idea of doing > "retail" vacuuming that operates by looking up index entries explicitly. > You could certainly make a retail vacuumer do nothing if it fails to > find the expected index entry, but ISTM that'd be a rather serious loss > of consistency checking --- you could not tell the someone-already- > deleted-it case apart from a bug in the vacuumer's index value > computation or lookup. > > Personally I don't think retail vacuuming in that form will ever fly > anyway, so I have no problem with installing the proposed patch, > but I thought I'd better throw this comment out to see if anyone > thinks it's a big deal. Agreed. Reverse lookup of index entries will always be too slow. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: