Laurette,
It's not that easy. As soon as you do any operation on
a column you the optimizer can no longer use a normal
index. That's exactly why funcional indexes were
introduced.
It's easy to create
CREATE INDEX min_evtime
ON positions_plus (MIN(evtime));
BTW functional indexes were a new f
On Wed, Sep 18, 2002 at 01:59:13PM -0700, Laurette Cisneros wrote:
> But, having read the postings, I must cast my vote for fixing at least the
> standard aggregates so that they work faster (by being smarter). I realize
> that there is a trade off for allowing the building of custom aggregates
Yes, indeed.
The workaround was quite simple (for min and max).
But, having read the postings, I must cast my vote for fixing at least the
standard aggregates so that they work faster (by being smarter). I realize
that there is a trade off for allowing the building of custom aggregates
but it
On Wed, Sep 18, 2002 at 13:09:07 -0700,
Laurette Cisneros <[EMAIL PROTECTED]> wrote:
>
> Aren't aggregates smart enough to use an index on the column? This takes 8
> minutes to run! I can't see that I should have to build a functional index
> (is it possible for an aggregate?) to get this to
Not sure the right forum to post this...
I have a table that has 20 million rows and growing. One of the columns is a
timestamptz column.
If I do:
explain select * from bigtable where tscol > '2002-09-17';
I see:
NOTICE: QUERY PLAN:
Index Scan using pos_timeidx on positions_plus (cost=0.
