That's one of the draw back of MVCC.
I once suggested that the transaction number and other house keeping
info be included in the index, but was told to forget it...
It would solve once and for all the issue of seq_scan vs index_scan.
It would simplify the aggregate problem.
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