Reiner Dassing <[EMAIL PROTECTED]> writes:
> Here is another example, which is even worse:
> select value from table where id=1 order by epoch desc limit 1;
> to ask for the last stored value.
> This request needs about 5 minutes to complete.
Hm. That should produce a decent plan given the right
Bruce Momjian wrote:
>
> The larger problem is that count(*) doesn't use the index at all. It
> just does a sequential scan of the heap table.
Here is another example, which is even worse:
select value from table where id=1 order by epoch desc limit 1;
to ask for the last stored value.
This re
> > I assume the user is concerned about non-balanced btrees.
> That is correct!
> As I tested an example database with about 7 million entries on PostgreSQL V
> 6.5.2
> and the result of
> select count(*) from table;
> tooks about 3 minutes I have this concern.
> May be version 7.0.3 will give
Bruce Momjian wrote:
>
> > Reiner Dassing <[EMAIL PROTECTED]> writes:
> > > The primary index must be the epoch.
> > > As there will be no deletion from this data I fear - due to the
> > > internal representation of B-trees - the performance will degrade very
> > > soon.
> >
> > Nonsense. btree
> Reiner Dassing <[EMAIL PROTECTED]> writes:
> > The primary index must be the epoch.
> > As there will be no deletion from this data I fear - due to the
> > internal representation of B-trees - the performance will degrade very
> > soon.
>
> Nonsense. btree should work just fine for that. Use
Reiner Dassing <[EMAIL PROTECTED]> writes:
> The primary index must be the epoch.
> As there will be no deletion from this data I fear - due to the
> internal representation of B-trees - the performance will degrade very
> soon.
Nonsense. btree should work just fine for that. Use a timestamp
co
