Re: visibility maps

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: visibility maps
Дата
Msg-id 2e78013d0812110809q5a656eabu51960ba8fb7282f3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: visibility maps  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: visibility maps  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>
>
> I'm not sure if we should set the bits in very aggressively. If we're more
> aggressive about setting the bits, it also means that we have to clear the
> bits more often, increasing the likelihood of contention that you were
> worried about.

Well, I would rather set bits aggressively and reduce contention by
changing the lock type. If HOT is working well, VACUUM will have very
few things to do, but visibility map wouldn't help as much as it can
unless we set the bits after pruning.

Another thing I noticed is the since VACUUM tries to set the bit in
the first phase, it's working only because HOT prunes DEAD tuples just
before we do another scan on line pointers (which I had earlier talked
about getting rid of. May be its time I do that). Otherwise, the
visibility bit won't be set even though the DEAD tuples will be
removed in the second scan and the rest are all LIVE tuples. So if we
at all want to take out the another scan of line pointers from the
first pass, we should rather push the work setting bits in the prune
code.

Thanks,
Pavan

-- 

Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: COCOMO & Indians