Skip site navigation (1) Skip section navigation (2)

Re: patch to implement ECPG side tracing / tracking ...

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Hans-Juergen Schoenig <hs(at)cybertec(dot)at>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>,Michael Meskes <meskes(at)postgresql(dot)org>,Zoltan Boszormenyi <zb(at)cybertec(dot)at>
Subject: Re: patch to implement ECPG side tracing / tracking ...
Date: 2010-01-14 13:29:19
Message-ID: 20100114132919.GA21948@feivel.credativ.lan (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 13, 2010 at 10:30:32PM +0100, Hans-Juergen Schoenig wrote:
> performance tune your precompiler application. in PostgreSQL it is
> currently a little hard to get from the log what is executed how
> often by which application in which speed and so on. so, we came up

Hard or impossible? I agree with the other replies that this looks more like a
functionality you'd want in the server rather than the client.

> why for prepared queries: we found out that Informix is heavily
> using prepared queries internally. we already fixed something in

If you want a general feature why do you only implement it for one case?

> this area (patch sent some time ago) and we were finally able to
> catch up with Informix performance-wise in this area (mostly cursor
> work). before this auto_prepare fix, we were sometimes 2-3 times

Which fix are you talking about? I don't really remember a performance
improvement fix. Did I simply forget it or did I miss something important?

> slower than Informix. saving on network time solved the job. now we
> are left with many many programs performing somehow strange and we
> need to check for every program why. a decent summary on exit wouldA

Well I guess this is what you get paid for.

> to make it short: it is impossible to port hundreds of applications
> to PostgreSQL without having the chance to trace what the
> precompiler is doing how often in which program via which
> connection. it is simply impossible. so, we really and desparately
> need this patch in.

I'm sorry, but this is neither true (we've done it before) nor a valid point
(project decisions are independant from your contracts). You can surely
implement whatever you want for your customer but for your patch to make it
into our source tree there should be an advantage fore more people.

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(at)jabber(dot)org
VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-01-14 13:39:44
Subject: Re: mailing list archiver chewing patches
Previous:From: Bernd HelmleDate: 2010-01-14 13:04:46
Subject: Re: Table size does not include toast size

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group