> The only connection to MVCC is that the "obvious" solution doesn't work,
> namely storing a cache of the aggregate in the table information.

Well, that solution also doesn't work if you use a WHERE condition or JOIN, 
now does it?

> So what would it take to implement this for "all" aggregates? Where I think
> "all" really just means min(), max(), first(), last().

Um, what the heck are first() and last()?   These are not supported aggregates 
... table rows are *not* ordered.

> For min() and max() it would have to indicate not only that only the first
> or last record is necessary but also the sort order to impose.

I think Tom already suggested this based on adding a field to CREATE 
AGGREGATE.  But I think implementation isn't as simple as you think it is.

> Now the problem I see is if there's no index on the sort order imposed, and
> the previous step wasn't a merge join or something else that would return
> the records in order then it's not necessarily any faster to sort the
> records and return only some. It might be for small numbers of records, but
> it might be faster to just read them all in and check each one for min/max
> the linear way.

Yes, Tom mentioned this also.  Working out the rules whereby the planner could 
decide the viability of index use is a non-trivial task.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to