On Fri, Dec 26, 2014 at 1:19 PM, Dan S <strd911@xxxxxxxxx> 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@xxxxxxxxxxxxx>: >> >> Dan S <strd911@xxxxxxxxx> 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 > > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
