From: Noah Misch <noah@leadboat.com>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Meskes <meskes@postgresql.org>
Cc: PG Hackers <pgsql-hackers@postgresql.org>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
Date: Mon, 2 Apr 2012 12:12:08 -0400
Message-ID: <20120402161208.GA18340@tornado.leadboat.com> (raw)
In-Reply-To: <4F74E6A7.8040204@cybertec.at>
References: <4F538B4C.1030605@cybertec.at>
<20120305185632.GE13348@tornado.leadboat.com>
<4F55A9AD.6050600@cybertec.at>
<20120306110658.GC15988@tornado.leadboat.com>
<CA+TgmoaBGLpW5V3nFES-McLbZyY_9nUvpnFLjT7zAYuVPu809A@mail.gmail.com>
<4F6D9893.3030300@cybertec.at>
<20120329004323.GA17329@tornado.leadboat.com>
<4F74409C.3050904@cybertec.at>
<20120329170341.GA4142@tornado.leadboat.com>
<4F74E6A7.8040204@cybertec.at>
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
> 2012-03-29 19:03 keltez?ssel, Noah Misch ?rta:
>>>> one of the new sections about readahead should somehow reference the hazard
>>>> around volatile functions.
>>> Done.
>> I don't see the mention in your latest patch. You do mention it for the
>> sqlerrd[2] compatibility stuff.
>
> sqlerrd[2] compatibility stuff? I mentioned it in section "ecpg-sqlca", this is the main
> documentation section, not the compatibility one AFAIK. Anyway, I now reference the volatile
> function hazard in the first paragraphs added to section "ecpg-cursors".
This patch adds two features, and those features are independent from a user
perspective. The primary feature is cursor readahead, and the secondary
feature is "ecpg --detect-cursor-resultset-size" (the referent of my above
"sqlerrd[2] compatibility stuff" reference). Each feature has independent
semantic implications when the application uses cursors on queries that call
volatile functions. Under --detect-cursor-resultset-size, we will execute
functions for all rows at OPEN time and again for each row at FETCH time.
When you declare a cursor with "READAHEAD n" and do not FETCH it to the end,
up to "n" unFETCHed rows will nonetheless have their functions executed. If
the volatile function is something like clock_timestamp(), the application
will observe the executions to have happened in clusters of "n" rather than in
step with the application's FETCH calls.
Your latest patch revision hints at the semantic implications for "ecpg
--detect-cursor-resultset-size", but it does not mention them for readahead.
Then again, perhaps it's sufficiently obvious to not warrant mention. Without
knowing internals, I would not expect users to guess the consequence of "ecpg
--detect-cursor-resultset-size". With readahead, it may be guessable enough.
Thanks,
nm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, zb@cybertec.at, robertmhaas@gmail.com, meskes@postgresql.org, heikki.linnakangas@enterprisedb.com, bruce@momjian.us
Subject: Re: ECPG FETCH readahead
In-Reply-To: <20120402161208.GA18340@tornado.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox