Why does postgres scan all the table? - postgresql

Question

I discovered that a query I am doing on indexed column results in a sequential scan:
mydatabase=> explain analyze SELECT account_id,num_tokens,tok_holdings FROM tokacct WHERE address='00000000000000000';
QUERY PLAN
--------------------------------------------------------------------------------------------------
Seq Scan on tokacct (cost=0.00..6.69 rows=1 width=27) (actual time=0.046..0.046 rows=0 loops=1)
Filter: (address = '00000000000000000'::text)
Rows Removed by Filter: 225
Planning time: 0.108 ms
Execution time: 0.075 ms
(5 rows)
mydatabase=>
However a \di shows I have a unique index:
mydatabase=> \di
List of relations
Schema | Name | Type | Owner | Table
--------+-------------------------+-------+--------+----------------
......
public | tokacct_address_key | index | mydb | tokacct
.....
My table is defined like this:
CREATE TABLE tokacct (
tx_id BIGINT NOT NULL,
account_id SERIAL PRIMARY KEY,
state_acct_id INT NOT NULL DEFAULT 0,
num_tokens INT DEFAULT 0,
ts_created INT DEFAULT 0,
block_created INT DEFAULT 0,
address TEXT NOT NULL UNIQUE
tok_holdings TEXT DEFAULT ''
);
As you can see, the address field is declared as UNIQUE. The \di also confirms there is an index. So, why does it use a sequential scan on the table ?
Seq Scan on tokacct (cost=0.00..6.69 rows=1 width=27) (actual time=0.046..0.046 rows=0 loops=1)

Answer 1

create one page table:
db=# create table small as select g, chr(g) from generate_series(1,200) g;
SELECT 200
db=# create index small_i on small(g);
CREATE INDEX
db=# analyze small;
ANALYZE
seq scan:
db=# explain (analyze, verbose, buffers) select g from small where g = 200;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on public.small (cost=0.00..3.50 rows=1 width=4) (actual time=0.044..0.045 rows=1 loops=1)
Output: g
Filter: (small.g = 200)
Rows Removed by Filter: 199
Buffers: shared hit=1
Planning time: 1.360 ms
Execution time: 0.066 ms
(7 rows)
create three page table:
db=# drop table small;
DROP TABLE
db=# create table small as select g, chr(g) from generate_series(1,500) g;
SELECT 500
db=# create index small_i on small(g);
CREATE INDEX
db=# analyze small;
ANALYZE
db=# explain (analyze, verbose, buffers) select g from small where g = 200;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Index Only Scan using small_i on public.small (cost=0.27..8.29 rows=1 width=4) (actual time=3.194..3.195 rows=1 loops=1)
Output: g
Index Cond: (small.g = 200)
Heap Fetches: 1
Buffers: shared hit=1 read=2
Planning time: 0.271 ms
Execution time: 3.747 ms
(7 rows)
now the table takes three pages and index - two, thus index is cheaper...
how do I know the number of pages? it says so in the (verbose) execution plan. And the table?
db=# select max(ctid) from small;
max
--------
(2,48)
(1 row)
Here 2, means page two (counts from zero).
or again from the verbose plan:
db=# set enable_indexonlyscan to off;
SET
db=# set enable_indexscan to off;
SET
db=# set enable_bitmapscan to off;
SET
db=# explain (analyze, verbose, buffers) select g from small where g = 200;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on public.small (cost=0.00..9.25 rows=1 width=4) (actual time=0.124..0.303 rows=1 loops=1)
Output: g
Filter: (small.g = 200)
Rows Removed by Filter: 499
Buffers: shared hit=3
Planning time: 0.105 ms
Execution time: 0.327 ms
(7 rows)
Here, hit=3