Search Postgresql Archives

Re: Table with many NULLS for indexed column yields strange query plan

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

 



"Peter J. Holzer" <hjp-pgsql@xxxxxx> writes:
> How is the selectivity of "type"? Would an index on that column help?

The EXPLAIN results say that the "type = 'Standard'" condition is
completely not selective: in both plans, there is no "Rows Removed by
Filter" indication where it's applied, indicating that it did not
filter out any rows.  Which is odd, because if that isn't removing
any rows, why is the planner overestimating the number of rows
retrieved from table2 by circa 10x?  Maybe a lack of stats for the
"type" column?

I also find it odd that the second plan is uselessly using an index for
table3 (I say "useless" because there's no index condition and no
apparent need for the result to be sorted).  I suspect the OP has been
putting his thumb on the scales in ways he hasn't bothered to tell us
about, like fooling with the cost parameters and/or disabling seqscans.

			regards, tom lane





[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