From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | David Rowley <dgrowley(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Windowing Function Patch Review -> Standard Conformance |
Date: | 2008-12-08 07:38:31 |
Message-ID: | 493CCEF7.3080402@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2008-12-08 08:00:49 | Re: Polymorphic types vs. domains |
Previous Message | Peter Eisentraut | 2008-12-08 07:17:56 | Re: Mostly Harmless: Welcoming our C++ friends |