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

help / color / mirror / Atom feed
From: Greg Smith <greg@2ndquadrant.com>
To: Jim Nasby <jim@nasby.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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: Wed, 18 May 2011 23:00:31 -0400
Message-ID: <4DD487CF.8010003@2ndquadrant.com> (raw)
In-Reply-To: <B91EFACD-9560-45CB-8614-120D57B5A2F0@nasby.net>
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>
	<16676.1305560805@sss.pgh.pa.us>
	<B91EFACD-9560-45CB-8614-120D57B5A2F0@nasby.net>

Jim Nasby wrote:
> I think the challenge there would be how to define the scope of the hot-spot. Is it the last X pages? Last X serial values? Something like correlation?
>
> Hmm... it would be interesting if we had average relation access times for each stats bucket on a per-column basis; that would give the planner a better idea of how much IO overhead there would be for a given WHERE clause

You've already given one reasonable first answer to your question here.  
If you defined a usage counter for each histogram bucket, and 
incremented that each time something from it was touched, that could 
lead to a very rough way to determine access distribution.  Compute a 
ratio of the counts in those buckets, then have an estimate of the total 
cached percentage; multiplying the two will give you an idea how much of 
that specific bucket might be in memory.  It's not perfect, and you need 
to incorporate some sort of aging method to it (probably weighted 
average based), but the basic idea could work.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books




view thread (43+ messages)  latest in thread

Message-ID: <4DD487CF.8010003@2ndquadrant.com>
Permalink:  ../4DD487CF.8010003@2ndquadrant.com/
Also on:    postgresql.org/message-id/4DD487CF.8010003@2ndquadrant.com

 · 

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: greg@2ndquadrant.com, jim@nasby.net, 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: <4DD487CF.8010003@2ndquadrant.com>

* 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