Re: Poor Performance on Postgres 8.0
От | Pallav Kalva |
---|---|
Тема | Re: Poor Performance on Postgres 8.0 |
Дата | |
Msg-id | 41FA8697.1030200@deg.cc обсуждение исходный текст |
Ответ на | Re: Poor Performance on Postgres 8.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Poor Performance on Postgres 8.0
|
Список | 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@deg.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 > > >
В списке pgsql-performance по дате отправления: