pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jesper Krogh <jesper@krogh.cc>
Cc: pgsql-performance@postgresql.org
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan
Date: Mon, 16 May 2011 11:46:45 -0400
Message-ID: <16676.1305560805@sss.pgh.pa.us> (raw)
In-Reply-To: <BANLkTikTWeZxWQFxM1SJg=0=OtCkCX_-dA@mail.gmail.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>
	<BANLkTikcVUeRfocJPe_W+jfi5k1+gcLnxg@mail.gmail.com>
	<4DD0195A.9040305@agliodbs.com>
	<BANLkTika=a95=Pm97Evi-Q7e_9vs4FnkCQ@mail.gmail.com>
	<4DD07855.8080907@postnewspapers.com.au>
	<4DD07B4E.1020503@2ndquadrant.com>
	<4DD0AB16.5060808@krogh.cc>
	<4DD0ACD0.1090801@krogh.cc>
	<BANLkTikTWeZxWQFxM1SJg=0=OtCkCX_-dA@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 16, 2011 at 12:49 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>> Ok, it may not work as well with index'es, since having 1% in cache may very
>> well mean that 90% of all requested blocks are there.. for tables in should
>> be more trivial.

> Tables can have hot spots, too.  Consider a table that holds calendar
> reservations.  Reservations can be inserted, updated, deleted.  But
> typically, the most recent data will be what is most actively
> modified, and the older data will be relatively more (though not
> completely) static, and less frequently accessed.  Such examples are
> common in many real-world applications.

Yes.  I'm not convinced that measuring the fraction of a table or index
that's in cache is really going to help us much.  Historical cache hit
rates might be useful, but only to the extent that the incoming query
has a similar access pattern to those in the (recent?) past.  It's not
an easy problem.

I almost wonder if we should not try to measure this at all, but instead
let the DBA set a per-table or per-index number to use, analogous to the
override we added recently for column n-distinct statistics ...

			regards, tom lane



view thread (43+ messages)  latest in thread

Message-ID: <16676.1305560805@sss.pgh.pa.us>
Permalink:  ../16676.1305560805@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/16676.1305560805@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, jesper@krogh.cc
  Subject: Re: reducing random_page_cost from 4 to 2 to force index scan
  In-Reply-To: <16676.1305560805@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox