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 19:57:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
explain analyze select * from common.string text1_
where text1_.value='squareFeet';

                                               QUERY PLAN
 Seq Scan on string text1_  (cost=0.00..4.41 rows=1 width=21) (actual 
time=0.283..0.322 rows=1 loops=1)
   Filter: (value = 'squareFeet'::text)
 Total runtime: 0.492 ms

I am not worried about this table as common.string has only 190 records, 
where as the other table common.attribute which is very big (200k 
records) i want it to use index scan on it . The matching column in 
common.attribute table has only 175 distinct records in common.attribute 
table , do you think that's the problem ? here is the full query again

select attribute0_.attributeid as attribut1_, attribute0_.stringvalue as 
    attribute0_.bigStringvalue as bigStrin3_, attribute0_.integervalue 
as integerv4_,
    attribute0_.numericvalue as numericv5_, attribute0_.datevalue as 
    attribute0_.booleanvalue as booleanv7_, attribute0_.fknamestringid 
as fknamest8_
from  common.attribute attribute0_, common.string text1_
where     (text1_.value='squareFeet' and     
and     (numericValue='775.0')

Tom Lane wrote:

>Pallav Kalva <pkalva(at)deg(dot)cc> writes:
>>still doesnt make use of the index on common.attribute table .
>What do you get from just plain
>explain analyze select * from common.string text1_
>where text1_.value='squareFeet';
>I get the impression that it must think this will yield a lot of rows.
>			regards, tom lane

In response to


pgsql-performance by date

Next:From: Dawid KuroczkoDate: 2005-01-28 19:59:05
Subject: Re: Flattening a kind of 'dynamic' table
Previous:From: Christopher BrowneDate: 2005-01-28 19:49:29
Subject: Re: PostgreSQL clustering VS MySQL clustering

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