Message-ID: <4E773E42.9000202@gmail.com>
Date: Mon, 19 Sep 2011 16:06:10 +0300
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: =?UTF-8?B?Q8OpZHJpYyBWaWxsZW1haW4=?=
 <cedric.villemain.debian@gmail.com>
CC: Stefan Keller <sfkeller@gmail.com>, pgsql-performance@postgresql.org,
	Tomas Vondra <tv@fuzzy.cz>
Subject: Re: PostgreSQL-related topics of theses and seminary works
	sought (Was: Hash index use presently(?) discouraged...)
References: 
 <CAFcOn28VoOwGNQJA=qLGXCpxa5p3q-Twqsq8KNBOBX33Cf8u2A@mail.gmail.com>
	<4E770D59.3090906@gmail.com>
	<CAF6yO=0Yj2uVafYcdp=fLyCzh4OMmHgFNHbPDSTQZtwqQYNUVQ@mail.gmail.com>
In-Reply-To: 
 <CAF6yO=0Yj2uVafYcdp=fLyCzh4OMmHgFNHbPDSTQZtwqQYNUVQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello.

I did read and AFAIR sometimes responded on this long discussions. The 
main point for me is that many DBAs dont want to have even more random 
plans with postgresql knowing what's in memory now and using this 
information directly in runtime. I also think this point is valid.
What I would like to have is to force some relations to be in memory by 
giving them fixed part of shared buffers and to tell postgresql they are 
in memory (lowering page costs) to have fixed optimal plans.

Best regards, Vitalii Tymchyshyn.

19.09.11 14:57, Cédric Villemain написав(ла):
> 2011/9/19 Vitalii Tymchyshyn<tivv00@gmail.com>:
>> 17.09.11 23:01, Stefan Keller написав(ла):
>>> * more... ?
>> What I miss from my DB2 UDB days are buffer pools. In PostgreSQL terms this
>> would be part of shared buffers dedicated to a relation or a set of
>> relations. When you have a big DB (not fitting in memory) you also usually
>> want some small tables/indexes be in memory, no matter what other load DB
>> has.
>> Complimentary features are:
>> 1) Relations preloading at startup - ensure this relation are in memory.
> you can use pgfincore extension to achieve that, for the OS cache. It
> does not look interesting to do that for shared_buffers of postgresql
> (the subject has been discussed and can be discussed again, please
> check mailling list archieve first)
>
>> 2) Per buffer pool (or relation) page costs - tell it that this
>> indexes/tables ARE in memory
> you can use tablespace parameters (*_cost) for that, it has been
> rejected for tables in the past.
> I did propose something to start to work in this direction.
> See "[WIP] cache estimates, cache access cost" in postgresql-hackers
> mailling list.
>
> This proposal let inform the planner of the table memory usage and
> take that into account.