Re: Table with many NULLS for indexed column yields strange query plan - Mailing list pgsql-general

From Tom Lane
Subject Re: Table with many NULLS for indexed column yields strange query plan
Date
Msg-id 10656.1583703114@sss.pgh.pa.us
Whole thread Raw
In response to Re: Table with many NULLS for indexed column yields strange queryplan  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: Table with many NULLS for indexed column yields strange queryplan  (greigwise <greigwise@comcast.net>)
List pgsql-general
"Peter J. Holzer" <hjp-pgsql@hjp.at> 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



pgsql-general by date:

Previous
From: stan
Date:
Subject: Re: Another INSTEAD OF TRIGGER question
Next
From: Christoph Moench-Tegeder
Date:
Subject: Re: Real application clustering in postgres.