Re: Unexpected sequential scan on an indexed column - Mailing list pgsql-performance

From Tom Lane
Subject Re: Unexpected sequential scan on an indexed column
Date
Msg-id 28141.1258334599@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected sequential scan on an indexed column  (Eddy Escardo-Raffo <eescardo@kikini.com>)
List pgsql-performance
Eddy Escardo-Raffo <eescardo@kikini.com> writes:
> For C, the planner estimated 10 thousand rows. For D, the planner estimated
> 100 thousand rows, yet for E the planner estimated only 1 row, which is the
> closest to reality. So, is there any way to specify a query that has a
> SUB-SELECT that returns a small set of values so that the planner treats it
> similar to how it treats statement E, or does statement E get its additional
> edge precisely from the fact that the restriction is defined by integer
> literals?

Currently there is no attempt to look at the exact contents of a VALUES
construct for planning purposes.  For the examples you're showing it
seems like the IN (list) notation is more compact and more widely used,
so improving the VALUES alternative doesn't seem that exciting.

            regards, tom lane

pgsql-performance by date:

Previous
From: Eddy Escardo-Raffo
Date:
Subject: Re: Unexpected sequential scan on an indexed column
Next
From: Laurent Laborde
Date:
Subject: Re: limiting performance impact of wal archiving.