2008/12/3 Tom Lane <tgl@sss.pgh.pa.us>:
> If this means a lot of contortion/complication in the upper-level code,
> seems like it'd be better to address the performance issue within
> tuplestore/buffile. We could keep separate buffers for write and read
> perhaps. But do you have real evidence of a performance problem?
> I'd sort of expect the kernel's disk cache to mitigate this pretty well.
>
> regards, tom lane
>
I don't have real evidence but reasoned it. No strace was done. So it
may not be cased by flushing out but this commit gets performance
quite better, to earlier patch performance, around 44sec from around
76sec.
http://git.postgresql.org/?p=~davidfetter/window_functions/.git;a=commitdiff;h=87d9b8ac5dca9fae5f3ac4f3218d8fb4eca8b5b0;hp=f1976a9d002b20006ac31ca85db27abcf56e9ea2
where pos = -1 means spool all rows until the end.
The "earlier" approach was buffering all the table and the newer
Heikki's approach was buffer on row by row while reading. The newest
is buffering row by row while reading during in memory, and holding
all the remaining tuples before reading after out to file, something
like hybrid method.
Regards,
--
Hitoshi Harada
