Re: ECPG FETCH readahead - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: ECPG FETCH readahead
Date
Msg-id 20120417035208.GA5465@feivel.credativ.lan
Whole thread Raw
In response to Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG FETCH readahead