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

Re: Poor Performance on Postgres 8.0

From: Pallav Kalva <pkalva(at)deg(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PERFORM <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Poor Performance on Postgres 8.0
Date: 2005-01-28 18:38:15
Message-ID: 41FA8697.1030200@deg.cc (view raw or flat)
Thread:
Lists: pgsql-performance
Hi Tom,

     I dropped the primary key constraint and ran the explain analyze on 
the same query and here is what i get seq scans on both the tables , 
still doesnt make use of the index on common.attribute table .


                                                         QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..5609.19 rows=1 width=104) (actual 
time=11.875..319.358 rows=1 loops=1)
   Join Filter: ("outer".fknamestringid = "inner".stringid)
   ->  Seq Scan on attribute attribute0_  (cost=0.00..5604.76 rows=1 
width=104) (actual time=11.541..318.649 rows=2 loops=1)
         Filter: (numericvalue = 775.0)
   ->  Seq Scan on string text1_  (cost=0.00..4.41 rows=1 width=4) 
(actual time=0.277..0.319 rows=1 loops=2)
         Filter: (value = 'squareFeet'::text)
 Total runtime: 319.496 ms


Tom Lane wrote:

>Pallav Kalva <pkalva(at)deg(dot)cc> writes:
>  
>
>>>begin;
>>>alter table common.string drop constraint pk_string_stringid;
>>>explain analyze ... same query ...
>>>rollback;
>>>
>>>      
>>>
>>       what do u mean by rollback exactly ? i can drop the pk constraint 
>>and run explain analyze and see how it behaves.
>>    
>>
>
>The point of the rollback is that you don't really make the pk
>constraint go away.  It is gone from the perspective of the EXPLAIN,
>but after you rollback it's back again.  Easier than rebuilding it...
>
>			regards, tom lane
>
>  
>



In response to

Responses

pgsql-performance by date

Next:From: Alexandre LeclercDate: 2005-01-28 19:26:57
Subject: Re: Flattening a kind of 'dynamic' table
Previous:From: Joe ConwayDate: 2005-01-28 18:24:37
Subject: Re: Flattening a kind of 'dynamic' table

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