Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 352BB1C0B196
	for <pgsql-performance@postgresql.org>;
	Fri, 20 Jul 2012 04:10:45 -0300 (ADT)
Received: from 10610.x.rootbsd.net ([204.109.60.69] helo=vps001.shopzeus.com)
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <gandalf@shopzeus.com>) id 1Ss7MI-0008Df-72
	for pgsql-performance@postgresql.org; Fri, 20 Jul 2012 07:10:44 +0000
Received: from [192.168.1.105] (localhost [127.0.0.1])
	by vps001.shopzeus.com (8.14.3/8.14.3) with ESMTP id q6K7AMOP091207;
	Fri, 20 Jul 2012 03:10:23 -0400 (EDT)
	(envelope-from gandalf@shopzeus.com)
Message-ID: <5009045F.8020502@shopzeus.com>
Date: Fri, 20 Jul 2012 09:10:23 +0200
From: Laszlo Nagy <gandalf@shopzeus.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: mandavi <mandavi@web.de>
CC: Scott Marlowe <scott.marlowe@gmail.com>, pgsql-performance@postgresql.org
Subject: Re: queries are fast after dump->restore but slow again
	after some days dispite vacuum
References: <loom.20120719T133136-384@post.gmane.org>
	<5007FFDD.5050103@dunslane.net>
	<loom.20120719T160306-28@post.gmane.org>
	<CAOR=d=0jKdsQPEduC4YFnhdGjEBVi5EZ9mFGS6b7_KL03M7kNw@mail.gmail.com>
	<CAGr8ZJ917Ko_kLrfkuUam32z_KVTr8Zy34f0jvvgE+djDv2i9A@mail.gmail.com>
In-Reply-To: 
 <CAGr8ZJ917Ko_kLrfkuUam32z_KVTr8Zy34f0jvvgE+djDv2i9A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201207/240
X-Sequence-Number: 47421

>> Are you running a lot of full table updates?
> If you mean updates which are applied on every or almost every row of
> the table - yes, it happens with two rather small tables of max. 10
> 000 rows. But they are both not touched by the query with this big
> performance difference.
I'm not an expert, but would it help to change fillfactor to about 45%? 
I'm just guessing that full table updates with fillfactor=45% could 
store the rows on the same page. Maybe I'm wrong.