| From: | Michael Meskes <meskes(at)postgresql(dot)org> |
|---|---|
| To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Subject: | Re: ECPG FETCH readahead |
| Date: | 2012-04-16 16:04:48 |
| Message-ID: | 20120416160448.GA9968@feivel.credativ.lan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2012-04-16 16:19:40 | Re: JSON for PG 9.2 |
| Previous Message | Merlin Moncure | 2012-04-16 14:40:41 | Re: JSON for PG 9.2 |