On Fri, Dec 26, 2014 at 1:19 PM, Dan S <strd911@gmail.com> wrote:
> Well I'm trying to implement a window-function that works on range_types and
> produces 'atomic ranges' for each input range.
> Let's say I have a set of ranges some overlapping some not, and I want to
> split each range at every boundary of every overlapping range and return
> those.
> So for each range r I want to return an array of ranges that consists of
> range r split at every overlapping range boundary.
> I need to consider both upper and lower boundaries and to be able to do this
> in one pass over the data I need to sort both the upper and lower boundaries
> and also sort the original ranges so I can loop over the ranges and
> boundaries in lockstep to produce the arrays.
> As a last step I sort back the arrays of atomic ranges in the original order
> in the window so I can read out the tuplesort in that order and return each
> array to its corresponding range r.
>
> (The result can be used to answer questions like what are the maximum number
> of simultaneously overlapping ranges and at which ranges the maximum occurs)
>
> Best Regards
> Dan S
>
>
>
> 2014-12-26 18:57 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>>
>> Dan S <strd911@gmail.com> writes:
>> > I'm trying to write a window function in C .
>> > In the function I'm using a tuplesort to sort the window data and then
>> > do
>> > some processing.
>>
>> Hmm ... why do you feel you need to do that? The window function's input
>> should already be sorted according to the window specification.
>>
>> > Now when I'm running the function I get this: 'WARNING: temporary file
>> > leak: File 43 still referenced'
>> > The warning comes from my failure to call tuplesort_end at the
>> > appropriate
>> > time.
>>
>> Unsurprising.
>>
>> > So I think I need to use some callback mechanism to get that to work.
>> > I've found some reference in the postgres source code to
>> > RegisterExprContextCallback which seemed promising but I have no idea
>> > how
>> > to get the right expression context to put in as the first argument to
>> > that
>> > function.
>>
>> I don't think there is one :-(. WindowAgg has a per-input-tuple econtext,
>> and a per-output-tuple econtext, but what you'd need for this is a
>> partition-lifespan econtext, which doesn't exist.
>>
>> It's possible that we could promote the "partcontext" memory context into
>> a full econtext so as to support this sort of behavior. But I'd want to
>> see a reasonably convincing use-case for it.
>>
>> regards, tom lane
>
>