On Tue, Oct 8, 2019 at 7:37 PM Arya F wrote:
> As my table has gotten bigger, it takes longer to get a single row back
> when querying a row by its btree index.
>
>
Is this in a probabilistic sense, they take longer on average, or has every
single access gotten slower? If the increase in size
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 wrote:
>
>
>> On Tue, Oct 8, 2019 at 7:37 PM Arya F
On Tue, Oct 8, 2019 at 7:37 PM Arya F 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
På onsdag 09. oktober 2019 kl. 01:37:06, skrev Arya F mailto:arya6...@gmail.com>>: 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
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
