Skip site navigation (1) Skip section navigation (2)

Re: ECPG FETCH readahead

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Michael Meskes <meskes(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: ECPG FETCH readahead
Date: 2011-12-29 09:46:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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(at)postgresql(dot)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

Attachment: ecpg-cursor-readahead-9.2-git-v5.patch
Description: text/x-patch (118.3 KB)

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-12-29 10:58:38
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Manabu OriDate: 2011-12-29 02:37:22
Subject: Re: spinlocks on HP-UX

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group