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.
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) |