Re: count(*) slow on large tables

Поиск
Список
Период
Сортировка
От Bruno Wolff III
Тема Re: count(*) slow on large tables
Дата
Msg-id 20031002195843.GA19021@wolff.to
обсуждение исходный текст
Ответ на count(*) slow on large tables  (Dror Matalon <dror@zapatec.com>)
Список pgsql-performance
On Thu, Oct 02, 2003 at 12:46:45 -0700,
  Dror Matalon <dror@zapatec.com> wrote:

Please keep replies copied to the list.

> When would it happen that a tuple be invisible to the current
> transaction? Are we talking about permissions?

They could be tuples that were changed by a transaction that hasn't committed
or in the case of serializable isolation, a transaction that committed after
the current transaction started.

>
> On Thu, Oct 02, 2003 at 02:39:05PM -0500, Bruno Wolff III wrote:
> > On Thu, Oct 02, 2003 at 12:15:47 -0700,
> >   Dror Matalon <dror@zapatec.com> wrote:
> > > Hi,
> > >
> > > I have a somewhat large table, 3 million rows, 1 Gig on disk,  and growing. Doing a
> > > count(*) takes around 40 seconds.
> > >
> > > Looks like the count(*) fetches the table from disk and goes through it.
> > > Made me wonder, why the optimizer doesn't just choose the smallest index
> > > which in my case is around 60 Megs and goes through it, which it could
> > > do in a fraction of the time.
> >
> > Because it can't tell from the index if a tuple is visible to the current
> > transaction and would still have to hit the table to check this. So that
> > performance would be a lot worse instead of better.
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> >                http://www.postgresql.org/docs/faqs/FAQ.html
>
> --
> Dror Matalon, President
> Zapatec Inc
> 1700 MLK Way
> Berkeley, CA 94709
> http://www.zapatec.com

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

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: further testing on IDE drives
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: TPC-R benchmarks