Re: BUG #14750: Seq Scan instead of Index Scan works without limitation

On Thu, Jul 20, 2017 at 3:40 AM, <buhhunyx(at)tut(dot)by> wrote:
> Seq Scan is fine except its ignore PRIMARY KEY and UNIQUE CONSTRAINT: in case result is found it should be immediatly returned to avoid scan rest of data:
>
> # explain analyze select accountid from accounts where accountname = 'accountId50';
> Seq Scan on accounts (cost=0.00..2.50 rows=1 width=12) (actual time=0.018..0.029 rows=1 loops=1)
> Filter: ((accountname)::text = 'accountId50'::text)
> Rows Removed by Filter: 119
> Planning time: 0.075 ms
> Execution time: 0.048 ms
>
> In product no 'LIMIT 1' specified because first found result expected; in case of huge amout simple queries difference is valuable:
>
> # explain analyze select accountid from accounts where accountname = 'accountId50' limit 1;
> Limit (cost=0.00..2.50 rows=1 width=12) (actual time=0.016..0.016 rows=1 loops=1)
> -> Seq Scan on accounts (cost=0.00..2.50 rows=1 width=12) (actual time=0.014..0.014 rows=1 loops=1)
> Filter: ((accountname)::text = 'accountId50'::text)
> Rows Removed by Filter: 50
> Planning time: 0.084 ms
> Execution time: 0.035 ms

I suppose that could be a valid query planner optimization, but it
wouldn't apply often. The lack of that optimization isn't a bug, at
any rate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company