Re: ECPG FETCH readahead - Mailing list pgsql-hackers
From | Boszormenyi Zoltan |
---|---|
Subject | Re: ECPG FETCH readahead |
Date | |
Msg-id | 4EFC36EF.1060308@cybertec.at Whole thread Raw |
In response to | Re: ECPG FETCH readahead (Boszormenyi Zoltan <zb@cybertec.at>) |
Responses |
Re: ECPG FETCH readahead
|
List | pgsql-hackers |
Hi,
2011-11-16 20:51 keltezéssel, Boszormenyi Zoltan írta:
New patch attached against yesterday's GIT tree. Changes:
- documented the new ECPG_INVALID_CURSOR error code
- consistently free everything in error paths in cursor.c
2011-11-16 20:51 keltezéssel, Boszormenyi Zoltan írta:
2010-10-14 11:56 keltezéssel, Boszormenyi Zoltan írta:Hi, Robert Haas írta:On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes <meskes@postgresql.org> wrote:On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:Is there a reason not to enable it by default? I'm a bit worried that it will receive no testing if it's not always on.Yes, there is a reason, namely that you don't need it in native mode at all. ECPG can read as many records as you want in one go, something ESQL/C apparently cannot do. This patch is a workaround for that restriction. I still do not really see that this feature gives us an advantage in native mode though.So, who has the next action on this patch? Does Zoltan need to revise it, or does Michael need to review it, or where are we?Michael reviewed it shortly in private and I need to send a new revision anyway, regardless of his comments. I will refresh it ASAP.The ASAP took a little long. The attached patch is in git diff format, because (1) the regression test intentionally doesn't do ECPGdebug() so the patch isn't dominated by a 2MB stderr file, so this file is empty and (2) regular diff cannot cope with empty new files. Anyway, here is the new version with a new feature. Implementation details: - New ecpglib/cursor.c handles the client-side accounting of cursors. - Functions in ecpglib/execute.c are split into smaller functions so useful operations can be used by the new cursor.c - ecpg -r fetch_readahead enables readahead by default for all cursors. - Default readahead size is 256 rows, it can be modified by an environment variable, ECPGFETCHSZ. - *NEW FEATURE* Readahead can be individually enabled or disabled by ECPG-side grammar: DECLARE curname [ [ NO ] READAHEAD ] CURSOR FOR ... Without [ NO ] READAHEAD, the default behaviour is used for cursors. - Since the server and the client may disagree on the cursor position if readahead is used, ECPG preprocessor throws an error if WHERE CURRENT OF is used on such cursors. - The default assumed behaviour of cursors with readahead is NO SCROLL. If you want readahead and backward scrolling, SCROLL keyword is mandatory. The regression test creates a table with 513 rows, so it spans 2 full and 1 incomplete readahead window. It reads the table with two cursors, one with readahead and one without by 1 records forward and backward. This is repeated with reading 5 records at a time. Then the whole table is read into a chain of sqlda structures forward and backward. All other regression tests pass as well. The original regression tests also pass with these changes, the split of execute.c was risky in this regard. Now the split is done more cleanly than in the previous version, the file is not as rearranged as before.
New patch attached against yesterday's GIT tree. Changes:
- documented the new ECPG_INVALID_CURSOR error code
- consistently free everything in error paths in cursor.c
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.de http://www.postgresql.at/
Attachment
pgsql-hackers by date: