Re: ECPG FETCH readahead

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.de     http://www.postgresql.at/