pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
RES: Improving SQL performance
3+ messages / 2 participants
[nested] [flat]

* RES: Improving SQL performance
@ 2007-01-11 21:14 ` Carlos H. Reimer <carlos.reimer@opendb.com.br>
  2007-01-11 23:47   ` Re: RES: Improving SQL performance Cesar Suga <sartre@gmail.com>
  1 sibling, 1 reply; 3+ messages in thread

From: Carlos H. Reimer @ 2007-01-11 21:14 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance

Yes, I do have an index on tt_log.codcep.

Indexes I´ve on both tables:

tt_end
Indexes:
    "pk_end" PRIMARY KEY, btree (filcli, codcli, codfil, numend)
    "ak_end_numdoc" UNIQUE, btree (numdoc)
    "i_fk_end_darc" btree (codarc, tiparc)
    "i_fk_end_dend" btree (tipend)
    "i_fk_end_dfil" btree (codfil)
    "i_fk_end_dreg" btree (regiao)
    "i_fk_end_mun" btree (codcid)
tt_log
Indexes:
    "i_fk_log_bai" btree (codbai)
    "i_lc_log_codcep" btree (codcep)

Any clue?

Thanks!

Reimer


> -----Mensagem original-----
> De: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Enviada em: quinta-feira, 11 de janeiro de 2007 16:31
> Para: carlos.reimer@opendb.com.br
> Cc: pgsql-performance@postgresql.org
> Assunto: Re: [PERFORM] Improving SQL performance
>
>
> "Carlos H. Reimer" <carlos.reimer@opendb.com.br> writes:
> > 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?
>
> Seems the problem is not using an index for tt_log.  Do you have an
> index on tt_log.codcep?  If so, maybe you need to cast the result of
> the concatenation to char(8) to get it to use the index.
>
> 			regards, tom lane
>
>




^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: RES: Improving SQL performance
  2007-01-11 21:14 ` RES: Improving SQL performance Carlos H. Reimer <carlos.reimer@opendb.com.br>
@ 2007-01-11 23:47   ` Cesar Suga <sartre@gmail.com>
  0 siblings, 0 replies; 3+ messages in thread

From: Cesar Suga @ 2007-01-11 23:47 UTC (permalink / raw)
  To: carlos.reimer@opendb.com.br; +Cc: pgsql-performance

Hi, Carlos,

Wouldn't it be better if you used INT in 'codcep' in both tables (as 
CEP/ZIP numbers are [0-9]{8})? Casting as Tom Lane suggested is also a 
good alternative, yet I think it'd be much better if you used int in 
both columns.

Regards,
Cesar

Let's see the query:

SELECT ENDE.* , DEND.DESEND, DEND.USOEND, DEND.DUPEND,
               to_char('F') as NOVO,
               LOG.TIPLOG
          FROM TT_END ENDE LEFT OUTER JOIN TD_END DEND ON DEND.CODTAB = 
ENDE.TIPEND
                           LEFT OUTER JOIN TT_LOG LOG ON LOG.CODCEP = 
ENDE.CODCEP||CODLOG
         WHERE ENDE.FILCLI = '001'
           AND ENDE.CODCLI = ' 19475';
 



Carlos H. Reimer wrote:
> Yes, I do have an index on tt_log.codcep.
>
> Indexes I´ve on both tables:
>
> tt_end
> Indexes:
>     "pk_end" PRIMARY KEY, btree (filcli, codcli, codfil, numend)
>     "ak_end_numdoc" UNIQUE, btree (numdoc)
>     "i_fk_end_darc" btree (codarc, tiparc)
>     "i_fk_end_dend" btree (tipend)
>     "i_fk_end_dfil" btree (codfil)
>     "i_fk_end_dreg" btree (regiao)
>     "i_fk_end_mun" btree (codcid)
> tt_log
> Indexes:
>     "i_fk_log_bai" btree (codbai)
>     "i_lc_log_codcep" btree (codcep)
>
> Any clue?
>
> Thanks!
>
> Reimer
>
>
>   
>> -----Mensagem original-----
>> De: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> Enviada em: quinta-feira, 11 de janeiro de 2007 16:31
>> Para: carlos.reimer@opendb.com.br
>> Cc: pgsql-performance@postgresql.org
>> Assunto: Re: [PERFORM] Improving SQL performance
>>
>>
>> "Carlos H. Reimer" <carlos.reimer@opendb.com.br> writes:
>>     
>>> 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?
>>>       
>> Seems the problem is not using an index for tt_log.  Do you have an
>> index on tt_log.codcep?  If so, maybe you need to cast the result of
>> the concatenation to char(8) to get it to use the index.
>>
>> 			regards, tom lane
>>
>>
>>     
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>   




^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* RES: Improving SQL performance
@ 2007-01-12 17:37 ` Carlos H. Reimer <carlos.reimer@opendb.com.br>
  1 sibling, 0 replies; 3+ messages in thread

From: Carlos H. Reimer @ 2007-01-12 17:37 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance

Yes, casting the result improved the time response a lot.

Thank you!

Reimer



> -----Mensagem original-----
> De: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org]Em nome de Tom Lane
> Enviada em: quinta-feira, 11 de janeiro de 2007 16:31
> Para: carlos.reimer@opendb.com.br
> Cc: pgsql-performance@postgresql.org
> Assunto: Re: [PERFORM] Improving SQL performance 
> 
> 
> "Carlos H. Reimer" <carlos.reimer@opendb.com.br> writes:
> > 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?
> 
> Seems the problem is not using an index for tt_log.  Do you have an
> index on tt_log.codcep?  If so, maybe you need to cast the result of
> the concatenation to char(8) to get it to use the index.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 
> 



^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2007-01-12 17:37 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-01-11 21:14 ` Carlos H. Reimer <carlos.reimer@opendb.com.br>
2007-01-11 23:47   ` Cesar Suga <sartre@gmail.com>
2007-01-12 17:37 ` Carlos H. Reimer <carlos.reimer@opendb.com.br>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox