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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

--
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

Responses

Browse pgsql-hackers by date

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