Re: Sorted union
От | Merlin Moncure |
---|---|
Тема | Re: Sorted union |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3417DD798@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | Sorted union (Scott Lamb <slamb@slamb.org>) |
Ответы |
Re: Sorted union
|
Список | pgsql-performance |
> 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
В списке pgsql-performance по дате отправления: