On Sun, Nov 17, 2013 at 11:02 PM, KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> wrote: >>> However, my patch is on the way and needed to more improvement. I am >>> going >>> to add method of controlling readahead by GUC, for user can freely select >>> readahed parameter in their transactions. >> >> >> Rather, I'd try to avoid fadvising consecutive or almost-consecutive >> blocks. Detecting that is hard at the block level, but maybe you can >> tie that detection into the planner, and specify a sequential strategy >> when the planner expects index-heap correlation? > > I think we had better to develop these patches in step by step each patches, > because it is difficult that readahead optimizetion is completely come true > from a beginning of one patch. We need flame-work in these patches, first.
Well, problem is, that without those smarts, I don't think this patch can be enabled by default. It will considerably hurt common use cases for postgres. But I guess we'll have a better idea about that when we see how much of a performance impact it makes when you run those tests, so no need to guess in the dark. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
