[PERFORM] Trigger question

Hi, I am using pg 7.4.1 and have created a trigger over table with 3 M rows. If I start masive update on this table, pg executes this trigger on every row and dramaticaly slows the system. Exists in pg any way to define the trigger execution only if I have changes on some fields? For example I

Re: [PERFORM] Trigger performance

I need this info because I have a table with ~1.5 M rows and if I start to update 300 K from this rows it takes ~ 2h. If I remove the trigger for this table all the time is ~ 1 min. regards, ivan. Tom Lane wrote: pginfo [EMAIL PROTECTED] writes: I was supprised that the pgsql trigger take ~8

Re: [PERFORM] Trigger performance

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 difference

[PERFORM] slow vacuum performance

Hi, I am running pg 7.4.1 on linux box. I have a midle size DB with many updates and after it I try to run vacuum full analyze. It takes about 2 h. If I try to dump and reload the DB it take 20 min. How can I improve the vacuum full analyze time? My configuration: shared_buffers = 15000

Re: [PERFORM] slow vacuum performance

it). regards, ivan. Bill Moran wrote: pginfo wrote: Hi, I am running pg 7.4.1 on linux box. I have a midle size DB with many updates and after it I try to run vacuum full analyze. It takes about 2 h. If I try to dump and reload the DB it take 20 min. How can I improve the vacuum full

Re: [PERFORM] slow vacuum performance

Hi, scott.marlowe wrote: On Wed, 24 Mar 2004, pginfo wrote: Hi, I am running pg 7.4.1 on linux box. I have a midle size DB with many updates and after it I try to run vacuum full analyze. Is there a reason to not use just regular vacuum / analyze (i.e. NOT full)? Yes, in case I

Re: [PERFORM] slow vacuum performance

scott.marlowe wrote: On Wed, 24 Mar 2004, pginfo wrote: Hi, scott.marlowe wrote: On Wed, 24 Mar 2004, pginfo wrote: Hi, I am running pg 7.4.1 on linux box. I have a midle size DB with many updates and after it I try to run vacuum full analyze

Re: [PERFORM] [ SOLVED ] select count(*) very slow on an already

Hi , I am not sure, but I remember the same problem. It was ot 7.3.x version and and I needet to reindex the table. I think after 7.4 vacuum also work correct with reindex. But I am not sure. regards, ivan. Rajesh Kumar Mallah wrote: Hi, The problem was solved by reloading the Table. the

Re: [PERFORM] Wierd context-switching issue on Xeon

Hi, Dual Xeon P4 2.8 linux RedHat AS 3 kernel 2.4.21-4-EL-smp 2 GB ram I can see the same problem: procs memory swap io system cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 96212 61056 17202400

Re: [PERFORM] Major differences between oracle and postgres performance

Hi , I have similare problem and found that the problem is by pg sort. It is extremly slow by me. Also in my case I tryed to migrate one db from oracle to pg . To solve this problem I dinamicaly set sort_mem to some big value. In this case the sort is working into RAM and is relative fast.