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