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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal: COUNT(*) (and related) speedup
Дата
Msg-id 20929.1396631979@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: COUNT(*) (and related) speedup  (Joshua Yanovski <pythonesque@gmail.com>)
Ответы Re: Proposal: COUNT(*) (and related) speedup  (Joshua Yanovski <pythonesque@gmail.com>)
Re: Proposal: COUNT(*) (and related) speedup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Joshua Yanovski <pythonesque@gmail.com> writes:
>> But worse, what happens if a count(*)
>> is in progress?  It might or might not have scanned this page already,
>> and there's no way to get the right answer in both cases.  Counter
>> updates done by VACUUM would have a similar race-condition problem.

> I don't think the first part really matters.  If the page was visible
> when COUNT(*) started and then got dirtied by some other transaction,
> any changes by the second transaction shouldn't alter the actual count
> in our transaction anyway, so whether we scan the page needlessly or
> not seems beside the point.

The question is not whether you scan a page "needlessly" or not, it's
whether you double-count the tuples on it.  I don't think it's possible to
be sure that when you add the central counter value into your local sum,
you are neither double-counting nor omitting pages whose all-visible state
changed while you were scanning the table.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Using indices for UNION.
Следующее
От: Tom Lane
Дата:
Сообщение: Another thought about search_path semantics