Re: does "select count(*) from mytable" always do a seq

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: alex(at)neteconomist(dot)com
Cc: Scott Ribe <scott_ribe(at)killerbytes(dot)com>, Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: does "select count(*) from mytable" always do a seq
Date: 2005-01-10 17:23:42
Message-ID: 20050110172342.GA3855@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jan 10, 2005 at 11:51:51 -0500,
Alex Turner <armtuk(at)gmail(dot)com> wrote:
> I'm no database writing guru, but wouldn't it just be a matter of
> adding a transaction number to an index entry so as to determine it's
> newness and only retrieve entries with an older transaction number?

No, because transactions don't complete in the order they are started.
So you will need to be able to maintain some kind of list to cover
exceptions.

> I'm guessing that the theory is that most insert transactions will be
> committed, or only contain a small number of rows relative to the
> overall size of the table, and therefore the extra overhead of
> checking newer tuples won't impact the overall performance that much?
>
> I know I'm asking kind of deep questions that really don't affect much
> of anything, but I'm a devilishly curious individual, and I like
> understanding things that I use well. Feel free to tell me that it's
> irrelavant, or that I'm full of hot air and I don't have a good
> question ;)

There have been discussions in the past about why the core developers
feel that moving visibility status into indexes would be a net loss
on average. I don't think there has been one for a while, but you can
try searching the hackers archive.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Madison Kelly 2005-01-10 17:30:37 Re: SELECT from multiple tables (not join though)
Previous Message Madison Kelly 2005-01-10 17:22:41 SELECT from multiple tables (not join though)