2010/10/1 Tom Lane <[email protected]>: > Hitoshi Harada <[email protected]> writes: >> 2010/9/26 Pavel Stehule <[email protected]>: >>> This patch needs a few work - can share a compare functionality with >>> tuplesort.c, but I would to verify a concept now. > >> Sorry for delay. I read the patch and it seems the result is sane. For >> window function calls, I agree that the current tuplesort is not >> enough to implement median functions and the patch introduces its own >> memsort mechanism, although memsort has too much copied from >> tuplesort. It looks to me not so difficult to modify the existing >> tuplesort to guarantee staying in memory always if an option to do so >> is specified from caller. I think that option can be used by other >> cases in the core code. > > If this patch tries to force the entire sort to happen in memory, > it is not committable. What will happen when you get a lot of data? > You need to be working on a variant that will work anyway, not working > on an unacceptable lobotomization of the main sort code.
What about array_agg()? Doesn't it exceed memory even if the huge data come in? -- Hitoshi Harada -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
