Re: Block B-Tree concept

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Block B-Tree concept
Дата
Msg-id 200609270938.k8R9ccC05084@momjian.us
обсуждение исходный текст
Ответ на Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Block B-Tree concept  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> > Couldn't vacuum just eliminate tuples marked dead? Heck, don't we do
> > that anyway right now?
> 
> You mean _index_ tuples marked dead? Sure, no problem there.
> 
> > Granted, you'd want to periodically ensure that you scan the entire
> > index, but that shouldn't be horribly hard to set up.
> 
> Well, it seems to be.  A vacuum can't evaluate index expressions because 
> it's not in a real transaction.
> 
> The DBA could set up a cron job to do "SELECT * FROM foo WHERE bar > 0" 
> etc. with enable_seqscan=false? That would work, but we can't depend on 
> an additional administrative task like. And we might as well just 
> disable the optimization that's causing us problems.

Why can't the C code just do a full index scan that touches the heap,
sets those expired bits, and then do a vacuum?  My point is that the
bits can be set outside the normal vacuum process, so you don't have to
be doing heap lookups from the index inside vacuum.

Assuming the heap is mostly in index order, the full index scan
shouldn't take much longer than a heap scan, and if the heap doesn't
match index order, a block index shouldn't be used anyway.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Schaber
Дата:
Сообщение: Ignore that mail (was: jar in repository)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Block B-Tree concept