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

Hi, Tom Lane wrote: =?iso-8859-1?q?Gary=20Cowell?= <[EMAIL PROTECTED]> writes: -> Sort (cost=117865.77..119220.13 rows=541741 width=132) (actual time=63623.417..66127.641 rows=541741 loops=1) This is clearly where the time is going. sort_mem = 16384

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

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 172024000

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

[PERFORM] linux distro for better pg performance

Hi, I am using pg from 3 y. and generaly I do not have big problems with it. I am searching for best pg distro to run pg (7.4.1). At the moment I am using RedHat AS 3.0, but I think it have some performance problems (I am not sure). My configuration: P4 2.8 GHz 1 GB RAM 120 GB IDE 7200 disk. Kern

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 l

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

Re: [PERFORM] slow vacuum performance

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

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

Re: [PERFORM] Trigger performance

select ..." or "update mytable set ...where...". 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 <[EMAI

[PERFORM] Trigger performance

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

[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] go for a script! / ex: PostgreSQL vs. MySQL

Hi, Josh Berkus wrote: > Nick, > > > I reckon do a system scan first, and parse the current PostgreSQL conf > > file to figure out what the settings are. Also back it up with a date > > and time appended to the end to make sure there is a backup before > > overwriting the real conf file. Then a b

Re: [PERFORM] bad join performance

Ok, thanks for the help and best regards. ivan. Tom Lane wrote: > pginfo <[EMAIL PROTECTED]> writes: > > sorry for my bad. > > My production server is 7.3.7, but the development is 7.3.1 and I ran the > > tests on 7.3.1. > > > It is courios that on 7.3.1 the q

Re: [PERFORM] bad join performance

Hi tom, sorry for my bad. My production server is 7.3.7, but the development is 7.3.1 and I ran the tests on 7.3.1. It is courios that on 7.3.1 the query is not constantly bad. >From time to time it is running well. regards, ivan. Tom Lane wrote: > pginfo <[EMAIL PROTECTED]> writ

[PERFORM] bad join preformance

Hi , I am using pg 7.3.3 on RH 7.3, dual Athlon 1 GB RAM. I have 2 tables a_acc and a_vid_doc (all PK are int). sizes: select count(IDS) from a_acc; count - 1006772 select count(IDS) from a_vid_doc; count --- 25 I have problem with the join ot this tables. I tryed this exa

[PERFORM] bad join performance

Hi , I am using pg 7.3.3 on RH 7.3, dual Athlon 1 GB RAM. I have 2 tables a_acc and a_vid_doc (all PK are int). sizes: select count(IDS) from a_acc; count - 1006772 select count(IDS) from a_vid_doc; count --- 25 I have problem with the join ot this tables. I tryed this exa

Re: RE : [PERFORM] Query problem

Hi Bruno, I think I have tunet it. Pg is working for most of my selects, but I have problem with this one. regards, ivan Bruno BAGUETTE wrote: > Hello, > > > One of my selects is working much slower as in oracle. > > In this example I am using not many rows in tables. > > For all the joins I hav

[PERFORM] Query problem

Hi , I am working to migrate a oracle application to pg. I am using pg 7.3.3 on Dual PIII, 2 GB RAM,linux RedHat 7.3. One of my selects is working much slower as in oracle. In this example I am using not many rows in tables. For all the joins I have indexes. All IDS or IDS_xxx are name. Pls if i