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, 16 Apr 2012 06:24:57 +0200
Message-ID: <4F8B9F19.3040403@cybertec.at> (raw)
In-Reply-To: <20120416024636.GA4536@feivel.credativ.lan>
References: <4F74E6A7.8040204@cybertec.at>
<20120407112008.GA2286@feivel.credativ.lan>
<20120407155042.GB11987@tornado.leadboat.com>
<20120408142501.GA21513@feivel.credativ.lan>
<4F81BE55.1010904@cybertec.at>
<20120408173859.GA4915@feivel.credativ.lan>
<4F83E2B9.3030302@cybertec.at>
<20120410143722.GC6129@tornado.leadboat.com>
<20120410145501.GA11554@feivel.credativ.lan>
<4F847453.9060200@cybertec.at>
<20120416024636.GA4536@feivel.credativ.lan>
2012-04-16 04:46 keltezéssel, Michael Meskes írta:
> On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote:
>> With the above, it would be possible to use a comma separated list of "-r"
>> suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option.
> Yes, that sounds like a good plan. But of course it's outside the scope of this
> patch, so we can add this later on.
>
>> - Also added a note to the documentation about a possible performance trap
>> if a previously written ECPG application uses its own custom readahead via
>> multi-row FETCH statements.
> I didn't know that before you send this patch. Noah, did you?
>
> Frankly, I don't like this at all. If I got it right that means a FETCH N is
> essantially computed as N times FETCH 1 unless you either add a non-standard
> option to the DECLARE statement or you add a command-line option to ecpg. Did I
> get that right?
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".
> If so we would deliberately make ecpglib work incorrectly and remove
> performance. Why is that? I'm interested in what others think, but to me that
> sounds like a show-stopper.
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?
>
> Michael
>
--
----------------------------------
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: <4F8B9F19.3040403@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