Search Postgresql Archives

Re: Does indexing help >= as well as = for integer columns?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




This I don't get. Why is an index scan not used? Isn't an index supposed
to help when using > < >= <= too?

It should !

Explain Analyze Select count(smiles) from structure where _c >= 30
Aggregate (cost=196033.74..196033.74 rows=1 width=32) (actual time=42133.432..42133.434 rows=1
loops=1)
-> Seq Scan on structure (cost=0.00..191619.56 rows=1765669 width=32) (actual
time=8050.437..42117.062 rows=1569 loops=1)
Filter: (_c >= 30)
Total runtime: 42133.746 ms


	See these :

-> Index Scan using "Nc" on structure (cost=0.00..105528.89 rows=26486 width=32) (actualtime=0.098..16.095 rows=734 loops=1)
-> Seq Scan on structure (cost=0.00..191619.56 rows=1765669 width=32) (actual time=8050.437..42117.062 rows=1569 loops=1)


In the index scan case, Planner thinks it'll get "rows=26486" but in reality only gets 734 rows.
In the seq scan case, Planner thinks it'll get "rows=1765669" but in reality only gets 1569 rows.


The two are way off-mark. 26486 still makes it choose an index scan because it's a small fraction of the table, but 1765669 is not.

Analyze, use more precise statistics (alter table set statistics), whatever... but you gotta get the planner correctly estimating these rowcounts.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux