Hitoshi Harada wrote:
> 2009/1/15 Bruce Momjian :
> >
> > Has this been addressed?
>
> It is mentioned at
>
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
>
> * Look at tuplestore performance issues. The tuplestore_in_memory()
> thing is just a band-aid, we ought to try to s
"Hitoshi Harada" writes:
> 2009/1/15 Bruce Momjian :
>> Has this been addressed?
> It is mentioned at
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
> but not solved yet. It seems to me that to solve this the tuplestore's
> inside design should be changed much. In-file state
2009/1/15 Bruce Momjian :
>
> Has this been addressed?
It is mentioned at
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
* Look at tuplestore performance issues. The tuplestore_in_memory()
thing is just a band-aid, we ought to try to solve it properly.
tuplestore_advance seems
Has this been addressed?
---
Hitoshi Harada wrote:
> 2008/12/3 Tom Lane :
> > 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
> >
2008/12/3 Tom Lane <[EMAIL PROTECTED]>:
> 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
> 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.
>
Oh, I mean, 116sec to 44sec.
--
Hitoshi Harada
--
Sent via pgsql-hacker
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> While attacking this issue(*1), I found that tuplestore that is on the
> file status has potential performance problem.
> The performance problem introduced by Heikki's new approach was caused
> by BufFile's frequent flush out in such cases like you p
