Ask for disk type and set page_cost
See original GitHub issueBased on this article it would be useful to ask for the disk (HDD, SSD,…) and set the random_page_cost
, seq_page_cost
accordingly.
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
random_page_cost =1.1 and NVMe disk: slower query
In the id column, I inserted random numbers between 1 and 10,000,000. I inserted 10 millions rows. Then: CREATE INDEX ON t_1(id); SET...
Read more >High Sierra asking for 'disk password' and won't accept any
I've tried the MacOS password, Apple ID Password, FileVault recovery key, and iCloud recovery key and none let me in. What password does...
Read more >Using Diskpart to create, delete, clean or extend disk partitions
At the DISKPART prompt, type select volume 0 (Selects the volume.) At the DISKPART prompt, type extend (If you do not set a...
Read more >Set-Disk (Storage) - Microsoft Learn
Runs the cmdlet as a background job. Use this parameter to run commands that take a long time to complete. Type: SwitchParameter. Position:...
Read more >Set up scratch disks in Photoshop - Adobe Support
To improve performance, set the scratch disk to a defragmented hard disk that has plenty of unused space and fast read/write speeds. If...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @le0pard, a safe change for everyone would be this:
Technically the only thing it changes is Postgres using indexes more eagerly, affecting only planner, so nothing to benchmark - some plans query plans switch to using indexes.
random_page_cost basically says
“you’d better read 4x more data sequentially than read it by random index scan”.Setting
random_page_cost = 1.1
on SSD is pretty modest change. Further tweaking for system may get it lower, down toseq_page_cost
.Changing
seq_page_cost
is not normally necessary, what matters is ratio between random and seq scan - you need to get data from disk, and you’ll get it either randomly reading or sequentially reading 😃This change is critical for anyone who uses PostGIS as their index operations are much faster than on-disk operations, and there is currently no way in Postgres to inform planner about it.
It’s currently number one reason for “why are my indexes not being used?!” when debugging someone’s query in https://t.me/pgsql. Setting 1.1 usually solves issues.
Postgres developers recommend going as low as 1.0: http://www.sai.msu.su/~megera/postgres/talks/Everything-Indexes-v4.pdf
@Komzpa Thanks, added in pgtune. You can check with @dewey 😃