On Thu, Jun 12, 2014 at 12:17 AM, Gurjeet Singh <gurjeet@singh.im> wrote:
> On Wed, Jun 11, 2014 at 10:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Jun 10, 2014 at 10:03 PM, Gurjeet Singh <gurjeet@singh.im> wrote:
>>> And it's probably accepted by now that such a bahviour is not
>>> catastrophic, merely inconvenient.
>>
>> I think the whole argument for having pg_hibernator is that getting
>> the block cache properly initialized is important. If it's not
>> important, then we don't need pg_hibernator in the first place. But
>> if it is important, then I think not loading unrelated blocks into
>> shared_buffers is also important.
>
> I was constructing a contrived scenario, something that would rarely
> happen in reality. I feel that the benefits of this feature greatly
> outweigh the minor performance loss caused in such an unlikely scenario.
So, are you proposing this for inclusion in PostgreSQL core?
If not, I don't think there's much to discuss here - people can use it
or not as they see fit, and we'll see what happens and perhaps design
improvements will result, or not.
If so, that's different: you'll need to demonstrate the benefits via
convincing proof points, and you'll also need to show that the
disadvantages are in fact minor and that the scenario is in fact
unlikely. So far there are zero performance numbers on this thread, a
situation that doesn't meet community standards for a performance
patch.
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
