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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Table with many NULLS for indexed column yields strange query plan
Date: 2020-03-08 21:31:54
Message-ID: 10656.1583703114@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Peter J. Holzer" <hjp-pgsql(at)hjp(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christoph Moench-Tegeder 2020-03-08 23:01:50 Re: Real application clustering in postgres.
Previous Message stan 2020-03-08 21:13:25 Re: Another INSTEAD OF TRIGGER question