Re: Would SSD improve Index Only Scan performance by a lot?

From: Matthew Hall <mhall(at)mhcomputing(dot)net>
To: Rick Otten <rottenwindfish(at)gmail(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Would SSD improve Index Only Scan performance by a lot?
Date: 2019-10-09 03:17:13
Message-ID: 1483EB08-4FBB-46CE-9920-7FF12285C326@mhcomputing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

For indexes the SSDs are at least 4X faster but you won't get that to happen unless you fix the planner tunable for the random page fetch cost first. Super important change for SSDs.

Matthew Hall

> On Oct 8, 2019, at 5:12 PM, Rick Otten <rottenwindfish(at)gmail(dot)com> wrote:
>
>
>> On Tue, Oct 8, 2019 at 7:37 PM Arya F <arya6000(at)gmail(dot)com> wrote:
>> As my table has gotten bigger, it takes longer to get a single row back when querying a row by its btree index.
>>
>> Right now the database is running on a traditional HDD. SSDs have a much faster seek time than traditional HDDs.
>>
>> Would switching to an SSD improve "Index Only Scan" time greatly? by at least 3-4 times?
>
> *If* your query is disk I/O bound, SSD can help a lot.
>
> If your data is already in memory, or file system cache, and your query is bound by CPU or bloated/corrupted indexes, or some query inefficiency, then faster disks really won't do anything.
>
> Depending on the data type and size of the data you may be able to help your query performance by choosing an index type other than the out-of-the-box btree as well (such as a hash or brin index) or maybe even a different sort order on the index, or a partial index.
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Behrang Saeedzadeh 2019-10-09 06:21:23 Get the planner used by a query?
Previous Message Rick Otten 2019-10-09 00:12:48 Re: Would SSD improve Index Only Scan performance by a lot?