Re: ECPG FETCH readahead

Поиск
Список
Период
Сортировка
От Michael Meskes
Тема Re: ECPG FETCH readahead
Дата
Msg-id 20120416024636.GA4536@feivel.credativ.lan
обсуждение исходный текст
Ответ на Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
Ответы Re: ECPG FETCH readahead  (Boszormenyi Zoltan <zb@cybertec.at>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Last gasp
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Improving our clauseless-join heuristics