Re: ECPG FETCH readahead

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: 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-23 14:03:39
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


2012-04-17 06:48 keltezéssel, Michael Meskes írta:
> On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote:
>> I listed two scenarios.
>> 1. occasional bump of the readahead window for large requests,
>> for smaller requests it uses the originally set size
>> 2. permanent bump of the readahead window for large requests
>> (larger than previously seen), all subsequent requests use
>> the new size
>> Both can be implemented easily, which one do you prefer?
>> If you always use very large requests, 1) behaves like 2)
> I'd say let's go for #2. #1 is probably more efficient but not what the
> programmer asked us to do. After all it's easy to increase the window size
> accordingly if you want so as a programmer.
> Michael

OK, I will implement #2. Another question popped up: what to do
with FETCH ALL? The current readahead window size or temporarily
bumping it to say some tens of thousands can be used. We may not
know how much is the "all records". This, although lowers performance,
saves memory.

Please, don't apply this patch yet. I discovered a rather big hole
that can confuse the cursor position tracking if you do this:

DECLARE mycur;

If (n+m) is greater, but (n-m) is smaller than the number
of rows in the cursor, the backend's and the caching code's
ideas about where the cursor is will differ. I need to fix this
before it can be applied.

That will also need a new round of review. Sorry for that.

Best regards,
Zoltán Böszörményi

Zoltán Böszörményi
Cybertec Schönig& Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-04-23 15:52:21 Re: B-tree page deletion boundary cases
Previous Message Krzysztof Nienartowicz 2012-04-23 13:42:40 Namespace of array of user defined types is confused by the parser in insert?