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 stringva2_,
attribute0_.bigStringvalue as bigStrin3_, attribute0_.integervalue as integerv4_,
attribute0_.numericvalue as numericv5_, attribute0_.datevalue as datevalue,
attribute0_.booleanvalue as booleanv7_, attribute0_.fknamestringid as fknamest8_
from common.attribute attribute0_, common.string text1_
where (text1_.value='squareFeet' and attribute0_.fknamestringid=text1_.stringid)
and (numericValue='775.0')



Tom Lane wrote:

Pallav Kalva <[EMAIL PROTECTED]> 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






---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Reply via email to