On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote: > OK. I would like to stretch your agreement a little. :-) > ...
Yeah, you got a point here. > By the new FETCH request. Instead of the above, I imagined this: > - the runtime notices that the new request is larger than the current > readahead window size, modifies the readahead window size upwards, > so the next FETCH will use it > - serve the request's first 128 rows from the current cache > - for the 129th row, FETCH 1024 will be executed and the remaining > 768 rows will be served from the new cache That means window size goes up to 1024-128 for that one case? > - all subsequent requests use the new readahead size, 1024 Sounds reasonable to me. > So, there can be occasional one-time larger requests but > smaller ones should apply the set window size, right? Yes. I do agree that FETCH N cannot fetch N all the time, but please make it work like what you suggested to make sure people don't have to recompile. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
