Just for fun, another approach since I believe pg supports it:
select whateverFields
from object_val as outer
where (outer.object_id,
outer.object_val_type_id,outer.observation_date) IN
(select inner.object_id,
inner.object_val_type,max(inner.observation_date)
from object_val as inner
where inner.object_id = somevalueForObjectX
and inner.object_val_type = someValueForTypeA
and inner.observation_date <= yourReferenceDate
group by inner.object_id, inner.object_val_type)
The reason these subqueries should run quickly is because the
object_id,object_val_type,oberservation_date make up a composite key,
so the subquery should execute extremely fast, thus eliminating the
majority of the data when you want to display or act on other fields
from the object_val (as outer). I suppose if you don't need any
further information from object_val, and you are happy with the speeds,
Tom's method is smooth.
Adding the order by clause will take you out of the 'relational world'
and thus slow you down. My fear with the triggers and the separate
snapshot is that the delays are spread out and add questionable
complexity, and potentially uneccessary overhead to the application.
Something to consider (although admittedly it is arguably a weak
consideration in some circumstances) is the extra space, indexes, and
other factors such as additional time for backup routines (and
restoration) the extra table creates.
Best of luck,
am
"Silvela, Jaime (Exchange)" wrote:
> No, you can make this work just fine if you JOIN right.
> You're way is a more concise way of expressing it, though.
>
> Tom's trick
>
> SELECT DISTINCT ON (object_id, object_val_type_id) * from object_val
> ORDER BY object_id DESC, object_val_type_id DESC, observation_date
> DESC
>
> Runs about twice as fast as the GROUP BY ... HAVING, but definitely not
> as fast as keeping a separate table with only the latest observations,
> updated by triggers. I'll be testing out the differences in overall
> performance for my applications.
>
> Thanks for the suggestions,
> Jaime
>
