DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=h+G5BCylN/A6fCQn07IAN900imw9gyJF264Fwk9C3nh6RsGrzvIUoclfrF2ATAMn7Y
	QEOXwF56ZvuGZVesnELQ7bU/15GMVJVeOflZDv8il09ZqJ8wAwgcXFGqNlYHEMLAo1bd
	BP4h7wIc/mWyU5TFuylV1mUmH9nSMmqWJz6ww=
MIME-Version: 1.0
In-Reply-To: <4DD016B5.2080202@agliodbs.com>
References: <BANLkTikZhYc+h1=YDJfXwZEZc1tN3_VwCg@mail.gmail.com>
	<4DB6F4BB020000250003CEB9@gw.wicourts.gov>
	<BANLkTindB68ogMg8zrR7GrYEV+mQQddj0A@mail.gmail.com>
	<BANLkTik6OaVkJGEjs5--vcynUE36mWbzbg@mail.gmail.com>
	<2823.1305314437@sss.pgh.pa.us>
	<BANLkTimTqXAy7_KqQz_OW1RvMbDd9ojfqg@mail.gmail.com>
	<4DCD90F5.2010501@agliodbs.com>
	<BANLkTi=BTJ56m-OozcD8fH2kkHOqmA4fHA@mail.gmail.com>
	<4DD016B5.2080202@agliodbs.com>
Date: Sun, 15 May 2011 16:32:01 -0400
Message-ID: <BANLkTimucC_NL6oifiUHxjrt7V0+=zMxXw@mail.gmail.com>
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan
From: Robert Haas <robertmhaas@gmail.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, May 15, 2011 at 2:08 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> All true. =A0I 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. =A0In fact, there's good reason to suppose that, if you were selectin=
g
> 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. =A0They
> 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.

Well, anything's possible.  But I wonder whether the effects you are
describing might result from a reduction in the *number* of pages
accessed rather than a change in the access pattern.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company