From: Boszormenyi Zoltan <zb@cybertec.at>
To: Noah Misch <noah@leadboat.com>
To: Michael Meskes <meskes@postgresql.org>
To: Robert Haas <robertmhaas@gmail.com>
To: PG Hackers <pgsql-hackers@postgresql.org>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
Date: Mon, 23 Apr 2012 16:03:39 +0200
Message-ID: <4F95613B.2030904@cybertec.at> (raw)
In-Reply-To: <20120417044819.GA9043@feivel.credativ.lan>
References: <4F83E2B9.3030302@cybertec.at>
<20120410143722.GC6129@tornado.leadboat.com>
<20120410145501.GA11554@feivel.credativ.lan>
<4F847453.9060200@cybertec.at>
<20120416024636.GA4536@feivel.credativ.lan>
<4F8B9F19.3040403@cybertec.at>
<20120416160448.GA9968@feivel.credativ.lan>
<4F8C544F.4080708@cybertec.at>
<20120417035208.GA5465@feivel.credativ.lan>
<4F8CEB5A.100@cybertec.at>
<20120417044819.GA9043@feivel.credativ.lan>
Hi,
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;
MOVE ABSOLUTE n IN mycur;
MOVE BACKWARD m IN 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
Web: http://www.postgresql-support.dehttp://www.postgresql.at/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: zb@cybertec.at, noah@leadboat.com, meskes@postgresql.org, robertmhaas@gmail.com, heikki.linnakangas@enterprisedb.com, bruce@momjian.us
Subject: Re: ECPG FETCH readahead
In-Reply-To: <4F95613B.2030904@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox