> Merlin Moncure wrote:
> > hmm, try pushing the union into a subquery...this is better style
> > because it's kind of ambiguous if the ordering will apply
before/after
> > the union.
>
> Seems to be a little slower. There's a new "subquery scan" step.
I figured. However it's more correct, I'm not sure if the original
query is necessarily guaranteed to give the right answer (in terms of
ordering). It might though.
>
> > question: why do you want to flatten the table...is it not easier to
> > work with as records?
>
> For most things, yes. But I'm making a bunch of different graphs from
> these data, and a few of them are much easier with events. The best
> example is my concurrency graph. Whenever there's a start event, it
goes
> up one. Whenever there's a stop event, it goes down one. It's
completely
> trivial once you have it separated into events.
well, if you don't mind attempting things that are not trivial, how
about trying:
select t, (select count(*) from transaction where t between happened
and when_stopped) from
(
select ((generate_series(1,60) * scale)::text::interval) + '12:00
pm'::time as t
) q;
for example, to check concurrency at every second for a minute (starting
from 1 second) after 12:00 pm, (scale is zero in this case),
select t, (select count(*) from transaction where t between happened
and when_stopped) from
(
select (generate_series(1,60)::text::interval) + '12:00 pm'::time as
t
) q;
this could be a win depending on how much data you pull into your
concurrency graph. maybe not though.
Merlin
