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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alexandre Leclerc | 2005-01-28 19:26:57 | Re: Flattening a kind of 'dynamic' table |
Previous Message | Joe Conway | 2005-01-28 18:24:37 | Re: Flattening a kind of 'dynamic' table |