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

On Thu, Jul 20, 2017 at 3:40 AM,  <buhhunyx@tut.by> wrote:
> Seq Scan is fine except its ignore PRIMARY KEY and UNIQUE CONSTRAINT: in case result is found it should be immediatly
returnedto 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
differenceis 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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs