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

help / color / mirror / Atom feed
From: Greg Smith <greg@2ndquadrant.com>
To: tv@fuzzy.cz
Cc: Claudio Freire <klaussfreire@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance
Date: Wed, 27 Apr 2011 14:49:17 -0400
Message-ID: <4DB8652D.7010804@2ndquadrant.com> (raw)
In-Reply-To: <5c6c67e9f0c4abed2b7ac84e83fe1f32.squirrel@sq.gransy.com>
References: <DF2D5436-117C-4D02-9B3C-A55723B7DDE1@darkstatic.com>
	<20110412171855.GA14292@tux>
	<FC3A3A2B-3ECB-41BA-8F94-356D6FED3695@darkstatic.com>
	<4DA496FA.3070908@fuzzy.cz>
	<8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com>
	<4DA4BFA2.5060601@fuzzy.cz>
	<B93DFBBB-DA56-4044-A508-0B7E4A2CFD28@darkstatic.com>
	<4DA4D40A.4010200@fuzzy.cz>
	<A0B9339E-9D58-4842-A206-050B773360B6@darkstatic.com>
	<4DA56DA8020000250003C783@gw.wicourts.gov>
	<BANLkTinJqXqErAtQg--1MOaw2LJNFZmwOg@mail.gmail.com>
	<BANLkTimyWkoX8Dj=4CKAjhY82ibru-An7g@mail.gmail.com>
	<4DA6216E.9020907@fuzzy.cz>
	<BANLkTim_m-oz3UMXEKUdFjWJ6uuAza79cw@mail.gmail.com>
	<4DA63125.5070106@fuzzy.cz>
	<BANLkTikYtnzTfS8Yjc-3ap9kysXLLpJwmg@mail.gmail.com>
	<5c6c67e9f0c4abed2b7ac84e83fe1f32.squirrel@sq.gransy.com>

tv@fuzzy.cz wrote:
> Anyway I'm not an expert in this field, but AFAIK something like this
> already happens - btw that's the purpose of effective_cache_size.

effective_cache_size probably doesn't do as much as you suspect.  It is 
used for one of the computations for whether an index is small enough 
that it can likely be read into memory efficiently.  It has no impact on 
caching decisions outside of that.

As for the ideas bouncing around here for tinkering with 
random_page_size more automatically, I have a notebook with about a 
dozen different ways to do that I've come up with over the last few 
years.  The reason no work can be done in this area is because there are 
no standardized benchmarks of query execution in PostgreSQL being run 
regularly right now.  Bringing up ideas for changing the computation is 
easy; proving that such a change is positive on enough workloads to be 
worth considering is the hard part.  There is no useful discussion to be 
made on the hackers list that doesn't start with "here's the mix the 
benchmarks I intend to test this new model against".

Performance regression testing for the the query optimizer is a giant 
pile of boring work we get minimal volunteers interested in.  Nobody 
gets to do the fun model change work without doing that first though.  
For this type of change, you're guaranteed to just be smacking around 
parameters to optimize for only a single case without some broader 
benchmarking context.

-- 
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 (60+ messages)  latest in thread

Message-ID: <4DB8652D.7010804@2ndquadrant.com>
Permalink:  ../4DB8652D.7010804@2ndquadrant.com/
Also on:    postgresql.org/message-id/4DB8652D.7010804@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, tv@fuzzy.cz, klaussfreire@gmail.com
  Subject: Re: Performance
  In-Reply-To: <4DB8652D.7010804@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