Generalizing max and min - Mailing list pgsql-general

From Bruno Wolff III
Subject Generalizing max and min
Date
Msg-id 20030612003122.GA20239@wolff.to
Whole thread Raw
Responses Re: Generalizing max and min  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-general
I was thinking about how to generalize max and min and came up with
something that I think conceptually provides a better view of the
problem, but may not be of any practical help.

The generalization is that both max and min can be looked at as unions
over a set with a partial order operator. (You can also look at them
as intesection operators which may be more natural in other cases.)
The union operator for max is that the union of two items is the
greater of the two items according to the < operator. We can use an
index on < as a short cut because the union of two sets A and B is
equal to A if (and only if) B < A.

Another type of operator that would work similarly would be the union
of two dimensional boxes. If we had an index that would tell us
that a bunch of the boxes in the union were already contained in the
partially computed union then we know that they could all be safely
skipped.

So if you were to try to make use of this situation, I would think you
would want to define a subtype of aggregates for unions. They would
be defined by a supplied union function and an optional partial order.
The initial condition would always be null. The union function would
really need to be a function that had the appropiate properties
(include null union anything is equal to anything).

The hard problem is still trying to decide how to take advantage of the
index when it is available. Sometimes an index scan should be used,
sometimes a sequential scan and sometimes a query with multiple
aggregates should get broken up into multiple subqueries so that
multiple indexes can be used.

P.S. A good way to see the max can be viewed is a union is to consider
a number as representing the set of all numbers of that domain less than
or equal to that number.

pgsql-general by date:

Previous
From: Edmund Dengler
Date:
Subject: Re: Performance of query (fwd)
Next
From: Bruno Wolff III
Date:
Subject: Re: Performance of a query