Re: Proposal: COUNT(*) (and related) speedup

Поиск
Список
Период
Сортировка
От Joshua Yanovski
Тема Re: Proposal: COUNT(*) (and related) speedup
Дата
Msg-id CABz-M-G8y2zW+7+m99WATWL6FnzpcctVFior-84eQWFbarHjhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: COUNT(*) (and related) speedup  (Joshua Yanovski <pythonesque@gmail.com>)
Список pgsql-hackers
> VACUUM counter updates, on the other hand, initially seem more
> problematic, since if we grab the value of the counter, then VACUUM
> updates the counter and the visbility bits, and then we check which
> visibility bits are set, we might skip pages we really need to check
> (since we're using an old value for the counter).  But in practice I
> am pretty sure this is a nonissue, because as long as our COUNT(*)
> transaction is going, no pages can have their visibility bits marked
> unless they haven't been updated since the transaction started, which
> consequently means we won't see the counter updated (the counter is
> intended to be updated immediately before the visibility bit is set
> while VACUUMing).  Took me a while to figure this out, for thanks for
> pointing it out :)

Clarification: the counter may be updated, but never in a way that
affects the final result, because it can only be updated to reflect
statistics on pages that are fully visible to all current
transactions.  As long as we scan every page that was "really" dirty
at the start of our transactions, we can't really go wrong, since we
can recompute that information ourselves--we can just be better or
worse at avoiding redundant heap fetches.

-- 
Josh



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: GSoC proposal - "make an unlogged table logged"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Using indices for UNION.