Re: reducing random_page_cost from 4 to 2 to force index scan - Mailing list pgsql-performance

From Josh Berkus
Subject Re: reducing random_page_cost from 4 to 2 to force index scan
Date
Msg-id 4DD016B5.2080202@agliodbs.com
Whole thread Raw
In response to Re: reducing random_page_cost from 4 to 2 to force index scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reducing random_page_cost from 4 to 2 to force index scan
List pgsql-performance
Robert,

> All true.  I suspect that in practice the different between random and
> sequential memory page costs is small enough to be ignorable, although
> of course I might be wrong.

This hasn't been my experience, although I have not carefully measured
it.  In fact, there's good reason to suppose that, if you were selecting
50% of more of a table, sequential access would still be faster even for
an entirely in-memory table.

As a parallel to our development, Redis used to store all data as linked
lists, making every object lookup effectively a random lookup.  They
found that even with a database which is pinned in memory, creating a
data page structure (they call it "ziplists") and supporting sequential
scans was up to 10X faster for large lists.

So I would assume that there is still a coefficient difference between
seeks and scans in memory until proven otherwise.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

pgsql-performance by date:

Previous
From: Stuart Bishop
Date:
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan
Next
From: Josh Berkus
Date:
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan