From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
---|---|
To: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
Cc: | Paulo Scardine <paulos(at)cimed(dot)ind(dot)br>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Seqscan in MAX(index_column) |
Date: | 2003-09-04 15:10:55 |
Message-ID: | Pine.LNX.4.44.0309041703110.14280-100000@zigo.dhs.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 4 Sep 2003, Shridhar Daithankar wrote:
> > column? I think MAX() does not know or cares if a column is indexed, but...
>
> No. Postgresql uses MVCC which mean there could be multiple views of sample
> tuple active at the same time. There is no way to tell which is max. value for
> a column as definition of a committed value can be a moving target.
>
> It can not be cached, at least easily. That's the price to pay for MVCC. Same
> goes for select count(*) from table. That query has to end up with a sequential
> scan.
It does not have to be like that. Even with a mvcc database it can use the
index for max/min and in my opinion it should.
As far as I know the only reason why it's not implemented in postgresql is
because pg has a general aggregate model and max/min are implemented using
that. Still, max/min are special in that they are almost the only
aggregates that can use an index to deliver the result directly. Some day
someone should make max/min a special case in pg. Exactly how is the
question.
I don't know mssql much, but I guess you can't define your own aggregate
functions there? Then all aggregate functions are special anyway.
--
/Dennis
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-04 15:14:34 | Re: Win32 native port |
Previous Message | Shridhar Daithankar | 2003-09-04 14:40:33 | Re: Seqscan in MAX(index_column) |