Re: Make COUNT(*) Faster?

Поиск
Список
Период
Сортировка
От Steve Wampler
Тема Re: Make COUNT(*) Faster?
Дата
Msg-id 42CEA305.1050904@noao.edu
обсуждение исходный текст
Ответ на Re: Make COUNT(*) Faster?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Make COUNT(*) Faster?  (PFC <lists@boutiquenumerique.com>)
Re: Make COUNT(*) Faster?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-sql
Tom Lane wrote:
> Steve Wampler <swampler@noao.edu> writes:
> 
>>So, leave COUNT(*) alone.  But it would be very handy to have a
>>way to get an approximate table size that is more accurate than is
>>provided by a pg_class.reltuples that is only updated on vacuums.
> 
> If you want something cheap, you could use the same technique the
> planner uses nowadays: take RelationGetNumberOfBlocks() (which is
> guaranteed accurate) and multiply by reltuples/relpages.  I don't
> see anyplace where RelationGetNumberOfBlocks is directly exposed to
> users now, but it'd be trivial to code up a couple of C functions to
> provide this functionality.

Yes - this would be an excellent approximation for my needs!  The
solution that Dawid Kuroczko suggested (just call "explain select *
on ..." and parse the result) would be equivalent these days, right?
(I think in the 7.x versions the planner was just using pg_class.reltuples,
which wouldn't have helped.)  If true, I can handle that parsing myself
easily enough without exposing RelationGetNumberOfBlocks.

Thanks (Tom and Dawid)!

-- 
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.


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

Предыдущее
От: Bruno Wolff III
Дата:
Сообщение: Re: two sums in one query
Следующее
От: PFC
Дата:
Сообщение: Re: Make COUNT(*) Faster?