What do the statistics look like for an example table that the index I used
vs not? Is ((instance_id)::text = 'test01'::text) rare for the tables where
an index scan is happening and common for the tables where a sequential
scan is chosen? How many rows in these tables generally?
Am 23.04.20 um 12:30 schrieb Stefan Knecht:
There's no question that this is more expensive than just reading the
95 rows from the index directly and returning them
not sure, you can play with
enable_seqscan = off
and compare the costs. What is the setting for random_page_cost ?
Regards,
Thanks Andreas,
But I don't think that that's what's happening.
Take this example line:
-> Seq Scan on snap_20200328 s_23 (cost=0.00..51.73
rows=95 width=12) (actual time=0.007..0.225 rows=95 loops=1)
Filter: ((instance_id)::text = 'test01'::text)
Am 23.04.20 um 10:13 schrieb Stefan Knecht:
Seq Scan on snap_20200225 s (cost=0.00..1.19 rows=1 width=12)
the partition is very small, so it's cheaper to scan only the table (one
block) than index + table (1 + 1 block).
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
Hello all
Does anyone have an explanation for this?
Query uses only three columns of the table "snap" and all three are in an
index.
The planner seems to think that some partitions are better scanned in full.
Yet for the other half of them it's using the index just fine.
Can someone enlighten m
