Re: ECPG FETCH readahead - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: ECPG FETCH readahead
Date
Msg-id 20120416024636.GA4536@feivel.credativ.lan
Whole thread Raw
In response to Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
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?

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.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Last gasp
Next
From: Amit Kapila
Date:
Subject: Re: Improving our clauseless-join heuristics