Re: SeqScan vs. IndexScan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com>
Cc: "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: SeqScan vs. IndexScan
Date: 2018-04-18 22:33:18
Message-ID: 24997.1524090798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com> writes:
> I'm running the same query with "set enable_seqscan = on;" and "set
> enable_seqscan = off;":
> ...
> Why optimizer is choosing SeqScan (on cmn_user) in the first query,
> instead of an IndexScan, despite of SeqScan being more costly?

Because it cares about the total plan cost, not the cost of any one
sub-node. In this case, the total costs at the join level are fuzzily
the same, but the indexscan-based join has worse estimated startup cost,
so it prefers the first choice.

The real problem here is the discrepancy between estimate and reality
for the number of rows out of the sys_user scan; because of that, you're
going to get garbage choices at the join level no matter what :-(.
You should look into what's causing that misestimate and whether you
can reduce the error, perhaps by providing better stats or reformulating
the filter conditions in a way the optimizer understands better.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rajni Baliyan 2018-04-19 00:12:01 Re: pg_upgrade help
Previous Message Vitaliy Garnashevich 2018-04-18 22:14:48 SeqScan vs. IndexScan