2010/10/1 Tom Lane <t...@sss.pgh.pa.us>: > Hitoshi Harada <umi.tan...@gmail.com> writes: >> 2010/9/26 Pavel Stehule <pavel.steh...@gmail.com>: >>> 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
