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  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Hi,

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:

Previous
From: Manabu Ori
Date:
Subject: Re: spinlocks on HP-UX
Next
From: Simon Riggs
Date:
Subject: Re: 16-bit page checksums for 9.2