RES: RES: RES: [PERFORM] Improving select peformance

.filpgt = vencodpgt.filpgt) AND (ven.codpgt = vencodpgt.codpgt)) Total runtime: 1317306.468 ms (43 rows) Reimer > -Mensagem original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] nome de Tom Lane > Enviada em: quinta-feira, 2 de agosto de 2007 23:13 > Para: [EMA

RES: RES: [PERFORM] Improving select peformance

using the default join_collapse_limit? Thank you in advance! Reimer > -Mensagem original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] nome de Carlos H. > Reimer > Enviada em: quarta-feira, 1 de agosto de 2007 21:26 > Para: Alvaro Herrera > Cc: Tom Lane; pgsql-perfo

RES: RES: [PERFORM] Improving select peformance

x27;::bpchar) -> Seq Scan on tt_pla vencodpgt (cost=0.00..2.18 rows=18 width=24) (actual time=0.002..0.017 rows=18 loops=256) Total runtime: 9546.971 ms (46 rows) > -Mensagem original- > De: Alvaro Herrera [mailto:[EMAIL PROTECTED] > Enviada em: quarta-feira, 1 de ag

RES: [PERFORM] Improving select peformance

, but can this solution be considered or the problem is in another place? Thank you in advance! Reimer > -Mensagem original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] nome de Tom Lane > Enviada em: quinta-feira, 19 de julho de 2007 22:31 > Para: [EMAIL PROTEC

[PERFORM] Problems with posting

Hi, I'm trying to post the following message to the performance group but the message does not appears in the list. Can someone help to solve this issue? Thanks in advance! __

[PERFORM] Improving select peformance

Hi, One of our end users was complaining about a report that was taking too much time to execute and I´ve discovered that the following SQL statement was the responsible for it. I would appreciate any suggestions to improve performance of it. Thank you very much in advance!

[PERFORM] Disk saturation

Hi, One of our database server is getting some very high response times and I´m wondering what can be responsible for this issue. A strange behaviour in this server is the saturation number iostat is giving, an average of 20% for only 140 wkB/s or can I consider them normal numbers? It is a Fedo

RES: [PERFORM] Improving SQL performance

pgsql-performance@postgresql.org > Assunto: Re: [PERFORM] Improving SQL performance > > > "Carlos H. Reimer" <[EMAIL PROTECTED]> writes: > > I know that the problem with the following SQL is the "LOG.CODCEP = > > ENDE.CODCEP||CODLOG" condition, but what ca

RES: [PERFORM] Improving SQL performance

ensagem original- > De: Tom Lane [mailto:[EMAIL PROTECTED] > Enviada em: quinta-feira, 11 de janeiro de 2007 16:31 > Para: [EMAIL PROTECTED] > Cc: pgsql-performance@postgresql.org > Assunto: Re: [PERFORM] Improving SQL performance > > > "Carlos H. Reimer" <[EM

[PERFORM] Improving SQL performance

Hi, I know that the problem with the following SQL is the "LOG.CODCEP = ENDE.CODCEP||CODLOG" condition, but what can I do to improve the performance? Is there a type of index that could help or is there another way to build this SQL? Thank you in advance! explain analyze SELECT ENDE.* , DEND.DE

RES: [PERFORM] Bad iostat numbers

by day. Reimer > -Mensagem original- > De: Mark Kirkwood [mailto:[EMAIL PROTECTED] > Enviada em: quinta-feira, 30 de novembro de 2006 23:47 > Para: [EMAIL PROTECTED] > Cc: pgsql-performance@postgresql.org > Assunto: Re: [PERFORM] Bad iostat numbers > > > Carlos

RES: [PERFORM] Bad iostat numbers

> -Mensagem original- > De: David Boreham [mailto:[EMAIL PROTECTED] > Enviada em: sexta-feira, 1 de dezembro de 2006 00:25 > Para: [EMAIL PROTECTED] > Cc: pgsql-performance@postgresql.org > Assunto: Re: [PERFORM] Bad iostat numbers > > > Carlos H. Reimer wrote: > >

[PERFORM] Bad iostat numbers

Hi, I was called to find out why one of our PostgreSQL servers has not a satisfatory response time. The server has only two SCSI disks configurated as a RAID1 software. While collecting performance data I discovered very bad numbers in the I/O subsystem and I would like to know if I´m thinking co

RES: [PERFORM] Priority to a mission critical transaction

iority to a mission critical transaction > > > On Thu, Nov 23, 2006 at 03:40:15PM -0500, Brad Nicholson wrote: > > On Tue, 2006-11-21 at 21:43 -0200, Carlos H. Reimer wrote: > > > Hi, > > > > > > We have an application that is mission critical, normally very fas

[PERFORM] Priority to a mission critical transaction

Hi, We have an application that is mission critical, normally very fast, but when an I/O or CPU bound transaction appears, the mission critical application suffers. Is there a way go give some kind of priority to this kind of application? Reimer

RES: [PERFORM] Context switching

Hi,   Sorry, but this message was already post some days before!   Thank you!   Carlos   -Mensagem original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Em nome de Carlos H. ReimerEnviada em: quarta-feira, 1 de novembro de 2006 03:23Para: pgsql-performance@postgresql.orgAssunto:

[PERFORM] Context switching

Hi,   We've migrated one of our servers from pg 7.4 to 8.1 and from times to times (4 hours) the server start doing a lot of context switching and all transactions become very slow.   The average context switching for this server as vmstat shows is 1 but when the problem occurs it goes to 2