Horton

Re: ECPG FETCH readahead

Michael Meskes <meskes@postgresql.org>

View thread
From: Michael Meskes <meskes@postgresql.org>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Noah Misch <noah@leadboat.com>, Michael Meskes <meskes@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Bruce Momjian <bruce@momjian.us>
Date: 2012-04-16T16:04:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some "translator:" comments mangled by pgindent

  2. Make sure float4in/float8in accept all standard spellings of "infinity".

On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote:
> Yes, just like when the readahead window set to 256, FETCH 1024
> will iterate through 4 windows or FETCH 64 iterates through the
> same window 4 times. This is the idea behind the "readahead window".

Really? It's definitely not the idea behind FETCH 1024. Using the same window 4
times for FETCH 64 is the idea though, I agree.

> How about allowing the readahead window to be resized for the
> non-decorated case if the runtime encounters FETCH N and N is
> greater than the previous window?

To be resized by what? IMO a FETCH N should always be a FETCH N, no matter
what, i.e. if the readahead window is larger, use it, but even if it's smaller
we should still fetch N at the same time.

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