Re: count(*) slow on large tables

On Thu, Oct 02, 2003 at 12:46:45 -0700,
Dror Matalon <dror(at)zapatec(dot)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(at)zapatec(dot)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