Re: ECPG FETCH readahead - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: ECPG FETCH readahead
Date
Msg-id 20120408173859.GA4915@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 Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote:
> Do you want me to change this or will you do it? I am on holiday
> and will be back to work on wednesday.

I don't think waiting till later this week is a real problem.

> The possibility to test different readahead window sizes
> without modifying the source and recompiling was useful.

Sure, but you can still do that when not defining a fixed number in the
statement.

> The -R option simply provides a default without ornamenting
> the DECLARE statement.

Could you please incorporate these changes, too, when you're back from vacation?

> >I cannot find a test that tests the environment variable giving the fetch size.
> >Could you please point me to that?
>
> I didn't write such a test. The reason is that while variables are
> exported by make from the Makefile to the binaries run by make
> e.g.  CFLAGS et.al. for $(CC), "make check" simply runs pg_regress
> once which uses its own configuration file that doesn't have a
> way to set or unset an environment variable. This could be a useful
> extension to pg_regress though.

How about calling setenv() from the test program itself?

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: Andrew Dunstan
Date:
Subject: Re: Last gasp
Next
From: clover white
Date:
Subject: Is there any way to disable compiler optimization and enable debug?