Prev: access method: are disk pages mandatory?
Next: [COMMITTERS] pgsql: Add TCP keepalive support to libpq.
From: Bruce Momjian on 23 Jun 2010 16:42
Boszormenyi Zoltan wrote:
> Hi,
>
> we improved ECPG quite a lot in 9.0 because we worked and
> still working with an Informix to PostgreSQL migration project.
>
> We came across a pretty big performance problem that can be seen in
> every "naive" application that uses only FETCH 1, FETCH RELATIVE
> or FETCH ABSOLUTE. These are almost the only FETCH variations
> usable in Informix, i.e. it doesn't have the grammar for fetching N rows
> at once. Instead, the Client SDK libraries do caching themselves
> behind the scenes to reduce network turnaround time.

I assume our ecpg version supports >1 fetch values, even in Informix
mode. Does it make sense to add lots of code to our ecpg then?

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: =?ISO-8859-1?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= on 24 Jun 2010 03:27
Hi,

2010-06-23 22:42 keltez�ssel, Bruce Momjian �rta:
> Boszormenyi Zoltan wrote:
>
>> Hi,
>>
>> we improved ECPG quite a lot in 9.0 because we worked and
>> still working with an Informix to PostgreSQL migration project.
>>
>> We came across a pretty big performance problem that can be seen in
>> every "naive" application that uses only FETCH 1, FETCH RELATIVE
>> or FETCH ABSOLUTE. These are almost the only FETCH variations
>> usable in Informix, i.e. it doesn't have the grammar for fetching N rows
>> at once. Instead, the Client SDK libraries do caching themselves
>> behind the scenes to reduce network turnaround time.
>>
> I assume our ecpg version supports>1 fetch values, even in Informix
> mode. Does it make sense to add lots of code to our ecpg then?
>

I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
The ESQL/C or ECPG connector was already written
the Informix quirks in mind, so it fetches only one record
at a time passing it to the application. And similar performance
is expected from ECPG - which excpectation is not fulfilled
currently because libecpg doesn't do the same caching as
ESQL/C does.

And FYI, I haven't added a whole lot of code, most of the
code changes in the patch is execute.c refactoring.
ECPGdo() was split into several functions, the new parts
are still doing the same things.

I can make the test case much smaller, I only needed
to test crossing the readahead window boundary.
This would also make the patch much smaller.

And this readahead is not on by default, it's only activated
by "ecpg -r fetch_readahead".

Best regards,
Zolt�n B�sz�rm�nyi


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 24 Jun 2010 05:04
On 24/06/10 10:27, B�sz�rm�nyi Zolt�n wrote:
> And this readahead is not on by default, it's only activated
> by "ecpg -r fetch_readahead".

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: =?ISO-8859-1?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= on 24 Jun 2010 05:27
2010-06-24 11:04 keltez�ssel, Heikki Linnakangas �rta:
> On 24/06/10 10:27, B�sz�rm�nyi Zolt�n wrote:
>> And this readahead is not on by default, it's only activated
>> by "ecpg -r fetch_readahead".
>
> 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.

Because in the first step I wanted to minimize the impact
on regression test stderr results. This is what I mentioned
in the initial mail, I stuck to the original wording of ecpg_log()
messages in the split-up parts of the original ECPGdo() and
ecpg_execute() exactly for this reason. The usual policy for
ecpg_log() is to report the function name where it was issued.

I was also thinking about a new feature for pg_regress,
to compare stdout results of two regression tests automatically
so a difference can be reported as an error. It would be good
for automated testing of features in ECPG that can be toggled,
like auto-prepare and fetch readahead. It might come in handy
in other subsystems, too.

Best regards,
Zolt�n B�sz�rm�nyi


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Michael Meskes on 24 Jun 2010 08:10
On Wed, Jun 23, 2010 at 04:42:37PM -0400, Bruce Momjian wrote:
> I assume our ecpg version supports >1 fetch values, even in Informix
> mode. Does it make sense to add lots of code to our ecpg then?

Yes, it does. The big question that zoltan and I haven't figured out yet, is
whether it makes sense to add all this even for native ecpg mode.

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
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes(a)jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2
Prev: access method: are disk pages mandatory?
Next: [COMMITTERS] pgsql: Add TCP keepalive support to libpq.