Hitoshi Harada wrote:
It shows even though tuplestore trims its tuples and stays in memory rather than dumps them on files, the performance up is only 2 sec in 50 sec. So I concluded the optimization for row_number()/rank() etc doesn't pay for its more complexity in window function API. The bottleneck of the Window node origins from something else, like puttupleslot(), not Window node algorithm. Of course those issues should be tracked more precisely, for the window functions work I ignore them.
The negative impact of not trimming the tuplestore comes from having to do I/O to write the tuples to temporary file. I would've expected that to show up with 400 MB table, but maybe that still fits comfortably in OS cache. Anyway, I would expect there to be a big drop in performance after the tuplestore no longer fits in cache, and trimming it would eliminate that.
That said, we should try to get this committed ASAP, so I think we can live without the trimming for 8.4.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
