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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
