Skip site navigation (1) Skip section navigation (2)

Re: Query performance PLEASE HELP

From: Dmitry Tkach <dmitry(at)openratings(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Query performance PLEASE HELP
Date: 2003-01-31 22:20:25
Message-ID: (view raw or whole thread)
Lists: pgsql-general
Tom Lane wrote:

>Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
>>> is not really unique by itself, is it?
>>No. The (duns,type) combination is unique (type is 0 through 5).
>Well, if there are at most six of any duns value, then it's close enough
>to unique for planning purposes.  So that's not the problem.
>>- it DOES choose the name index sometimes (for some of the values for 
>>the name in the criteria), but it just doesn't seem to make any 
>>difference. Here is an example:
>The plan's not very intelligible when you don't show us the query ...
>			regards, tom lane
Sorry, it was the same query as before - just had 'COMP%' instead of 

rapidb# explain analyze 
select * from tradestyle ts, managed_supplier ms where and like 'COMP%' and ms.subscriber=74 order by limit 10; 


Limit  (cost=0.00..16.14 rows=1 width=192) (actual time=6926.37..297527.99 rows=10 loops=1) 

  ->  Nested Loop  (cost=0.00..16.14 rows=1 width=192) (actual time=6926.36..297527.94 rows=11 loops=1) 

        ->  Index Scan using tradestyle_name_idx on tradestyle ts  (cost=0.00..7.98 rows=1 width=35) (actual time=51.99..295646.78 rows=41020 loops=1) 

        ->  Index Scan using managed_supplier_idx on managed_supplier ms  (cost=0.00..5.82 rows=1 width=157) (actual time=0.04..0.04 rows=0 loops=41020) 

Total runtime: 297528.31 msec


In response to


pgsql-general by date

Next:From: Grzegorz NowakDate: 2003-01-31 22:29:20
Subject: basic access problem on W2K
Previous:From: Medi MontaseriDate: 2003-01-31 22:12:46
Subject: Re: Basic SQL join question

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group