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