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.
The median function checking a calling context - under window aggregate uses a just memory sort solution - and under standard aggregate context it uses a full tuplesort. It bases on request of window aggregate function - the final function have to be called more time - and it isn't possible with tuplesort. So as window aggregate it uses just memory sort limited with work_mem. Other usage is unlimited. Second option was a block median function under window aggregates. It this design possible? We cannot use any complex source under window aggregates, because there isn't any way to unlink it. Regards Pavel > > regards, tom lane > -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
