Re: [RFC] speed up count(*)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [RFC] speed up count(*)
Дата
Msg-id CA+TgmoaHPvPFPLSqFPdsjHgmByziUpZ86PkWfJVJa0n-ms71Uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] speed up count(*)  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
On Thu, Oct 21, 2021 at 4:29 PM Joe Conway <mail@joeconway.com> wrote:
> meh -- the people who expect this to be impossibly fast don't typically
> need or expect it to be exactly correct, and there is no way to make it
> "exactly correct" in someone's snapshot without doing all the work.

I think it could actually be WAY faster than it is if, as Andres says,
we had the ability to push the count operation inside the heap AM. I
believe we have a tendency to attribute complaints like this to people
have unreasonable expectations, but here I'm not sure the expectation
is unreasonable. I vaguely recall writing a special-purpose code to
count the number of tuples in relation years ago, and IIRC it was
blazingly fast compared to letting our executor do it.  I agree,
however, that an approximation can be faster still.

> That is why I didn't suggest making it the default. If you flip the
> switch, you would get a very fast approximation. If you care about
> accuracy, you accept it has to be slow.

I'm not really here to take a position on the proposal. It doesn't
excite me, because I have not run across any users in the combination
of circumstances you mention: query can't be changed, exact answer not
actually required, whole table being counted. But I am not here to
call you a liar either. If you run across users in that situation all
the time, then you do.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [RFC] speed up count(*)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: parallelizing the archiver