---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
"Manuel Wenger" <[EMAIL PROTECTED]> writes:
> We're having a performance problem with PostgresQL 8.0.2 running on
> RHEL3 Update 4. There is a frequently updated table logging all our ADSL
> customer logins which has 2 related triggers. An INSERT on that table,
> "calls", takes about 300ms to execu
We're having a performance problem with PostgresQL 8.0.2 running on
RHEL3 Update 4. There is a frequently updated table logging all our ADSL
customer logins which has 2 related triggers. An INSERT on that table,
"calls", takes about 300ms to execute according to the logs, and the
process takes up t
Hello
try prepared statements, PQexecPrepared
http://developer.postgresql.org/docs/postgres/libpq-exec.html
Regards
Pavel Stehule
On Thu, 22 Jan 2004, pginfo wrote:
> Hi,
>
> thanks for the answer.
> It is very interest, because I readet many times that if I write the trigger
> in "C" it will
Ok, thanks.
I will do it.
regards,
ivan.
Tom Lane wrote:
> pginfo <[EMAIL PROTECTED]> writes:
> > In wich case will this trigger work faster if write it in "C"?
>
> Given that the dominant part of the time will be spent down inside SPI
> in either case, I doubt you will be able to see much diffe
pginfo <[EMAIL PROTECTED]> writes:
> In wich case will this trigger work faster if write it in "C"?
Given that the dominant part of the time will be spent down inside SPI
in either case, I doubt you will be able to see much difference. You
need to think about how to optimize the invoked query, no
Hi,
thanks for the answer.
It is very interest, because I readet many times that if I write the trigger
in "C" it will work faster.
In wich case will this trigger work faster if write it in "C"?
In all my triggres I have "select " or "insert into mytable select ..."
or "update mytable set ...w
pginfo <[EMAIL PROTECTED]> writes:
> I was supprised that the pgsql trigger take ~8 sec. to insert this rows
> and the "C" trigger take ~ 17 sec.
The reason is that plpgsql caches the plan for the invoked SELECT,
whereas the way you coded the C function, it's re-planning that SELECT
on every call.
Hi,
I need to speed up the triggers that we are using and I began to make
some tests to compare the "C" and pgSQL trigger performance.
I try to write two identical test triggers (sorry I do not know very
good the pgsql C interface and I got one of examples and werite it) and
attached it on insert
